<feed xmlns='http://www.w3.org/2005/Atom'>
<title>pm24.git/drivers/net/wireless, branch v5.9</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://git.kobert.dev/pm24.git/atom?h=v5.9</id>
<link rel='self' href='https://git.kobert.dev/pm24.git/atom?h=v5.9'/>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/'/>
<updated>2020-09-28T22:00:15Z</updated>
<entry>
<title>net: core: introduce struct netdev_nested_priv for nested interface infrastructure</title>
<updated>2020-09-28T22:00:15Z</updated>
<author>
<name>Taehee Yoo</name>
<email>ap420073@gmail.com</email>
</author>
<published>2020-09-25T18:13:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=eff7423365a6938d2d34dbce989febed2ae1f957'/>
<id>urn:sha1:eff7423365a6938d2d34dbce989febed2ae1f957</id>
<content type='text'>
Functions related to nested interface infrastructure such as
netdev_walk_all_{ upper | lower }_dev() pass both private functions
and "data" pointer to handle their own things.
At this point, the data pointer type is void *.
In order to make it easier to expand common variables and functions,
this new netdev_nested_priv structure is added.

In the following patch, a new member variable will be added into this
struct to fix the lockdep issue.

Signed-off-by: Taehee Yoo &lt;ap420073@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>mt76: mt7615: reduce maximum VHT MPDU length to 7991</title>
<updated>2020-09-24T13:12:22Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2020-09-23T05:24:42Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=efb1676306f664625c0c546dd10d18d33c75e3fc'/>
<id>urn:sha1:efb1676306f664625c0c546dd10d18d33c75e3fc</id>
<content type='text'>
After fixing mac80211 to allow larger A-MSDUs in some cases, there have been
reports of performance regressions and packet loss with some clients.
It appears that the issue occurs when the hardware is transmitting A-MSDUs
bigger than 8k. Limit the local VHT MPDU size capability to 7991, matching
the value used for MT7915 as well.

Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200923052442.24141-1-nbd@nbd.name
</content>
</entry>
<entry>
<title>Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver"</title>
<updated>2020-09-07T08:39:32Z</updated>
<author>
<name>Mauro Carvalho Chehab</name>
<email>mchehab+huawei@kernel.org</email>
</author>
<published>2020-08-26T05:49:34Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=1264c1e0cfe55e2d6c35e869244093195529af37'/>
<id>urn:sha1:1264c1e0cfe55e2d6c35e869244093195529af37</id>
<content type='text'>
This patch causes a regression betwen Kernel 5.7 and 5.8 at wlcore:
with it applied, WiFi stops working, and the Kernel starts printing
this message every second:

   wlcore: PHY firmware version: Rev 8.2.0.0.242
   wlcore: firmware booted (Rev 8.9.0.0.79)
   wlcore: ERROR command execute failure 14
   ------------[ cut here ]------------
   WARNING: CPU: 0 PID: 133 at drivers/net/wireless/ti/wlcore/main.c:795 wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore]
   Modules linked in: wl18xx wlcore mac80211 libarc4 cfg80211 rfkill snd_soc_hdmi_codec crct10dif_ce wlcore_sdio adv7511 cec kirin9xx_drm(C) kirin9xx_dw_drm_dsi(C) drm_kms_helper drm ip_tables x_tables ipv6 nf_defrag_ipv6
   CPU: 0 PID: 133 Comm: kworker/0:1 Tainted: G        WC        5.8.0+ #186
   Hardware name: HiKey970 (DT)
   Workqueue: events_freezable ieee80211_restart_work [mac80211]
   pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--)
   pc : wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore]
   lr : wl12xx_queue_recovery_work+0x24/0x30 [wlcore]
   sp : ffff8000126c3a60
   x29: ffff8000126c3a60 x28: 00000000000025de
   x27: 0000000000000010 x26: 0000000000000005
   x25: ffff0001a5d49e80 x24: ffff8000092cf580
   x23: ffff0001b7c12623 x22: ffff0001b6fcf2e8
   x21: ffff0001b7e46200 x20: 00000000fffffffb
   x19: ffff0001a78e6400 x18: 0000000000000030
   x17: 0000000000000001 x16: 0000000000000001
   x15: ffff0001b7e46670 x14: ffffffffffffffff
   x13: ffff8000926c37d7 x12: ffff8000126c37e0
   x11: ffff800011e01000 x10: ffff8000120526d0
   x9 : 0000000000000000 x8 : 3431206572756c69
   x7 : 6166206574756365 x6 : 0000000000000c2c
   x5 : 0000000000000000 x4 : ffff0001bf1361e8
   x3 : ffff0001bf1790b0 x2 : 0000000000000000
   x1 : ffff0001a5d49e80 x0 : 0000000000000001
   Call trace:
    wl12xx_queue_recovery_work.part.0+0x6c/0x74 [wlcore]
    wl12xx_queue_recovery_work+0x24/0x30 [wlcore]
    wl1271_cmd_set_sta_key+0x258/0x25c [wlcore]
    wl1271_set_key+0x7c/0x2dc [wlcore]
    wlcore_set_key+0xe4/0x360 [wlcore]
    wl18xx_set_key+0x48/0x1d0 [wl18xx]
    wlcore_op_set_key+0xa4/0x180 [wlcore]
    ieee80211_key_enable_hw_accel+0xb0/0x2d0 [mac80211]
    ieee80211_reenable_keys+0x70/0x110 [mac80211]
    ieee80211_reconfig+0xa00/0xca0 [mac80211]
    ieee80211_restart_work+0xc4/0xfc [mac80211]
    process_one_work+0x1cc/0x350
    worker_thread+0x13c/0x470
    kthread+0x154/0x160
    ret_from_fork+0x10/0x30
   ---[ end trace b1f722abf9af5919 ]---
   wlcore: WARNING could not set keys
   wlcore: ERROR Could not add or replace key
   wlan0: failed to set key (4, ff:ff:ff:ff:ff:ff) to hardware (-5)
   wlcore: Hardware recovery in progress. FW ver: Rev 8.9.0.0.79
   wlcore: pc: 0x0, hint_sts: 0x00000040 count: 39
   wlcore: down
   wlcore: down
   ieee80211 phy0: Hardware restart was requested
   mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
   mmc_host mmc0: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0)
   wlcore: PHY firmware version: Rev 8.2.0.0.242
   wlcore: firmware booted (Rev 8.9.0.0.79)
   wlcore: ERROR command execute failure 14
   ------------[ cut here ]------------

Tested on Hikey 970.

This reverts commit 2b7aadd3b9e17e8b81eeb8d9cc46756ae4658265.

Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/f0a2cb7ea606f1a284d4c23cbf983da2954ce9b6.1598420968.git.mchehab+huawei@kernel.org
</content>
</entry>
<entry>
<title>mwifiex: Increase AES key storage size to 256 bits</title>
<updated>2020-08-27T13:16:04Z</updated>
<author>
<name>Maximilian Luz</name>
<email>luzmaximilian@gmail.com</email>
</author>
<published>2020-08-25T15:38:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=4afc850e2e9e781976fb2c7852ce7bac374af938'/>
<id>urn:sha1:4afc850e2e9e781976fb2c7852ce7bac374af938</id>
<content type='text'>
Following commit e18696786548 ("mwifiex: Prevent memory corruption
handling keys") the mwifiex driver fails to authenticate with certain
networks, specifically networks with 256 bit keys, and repeatedly asks
for the password. The kernel log repeats the following lines (id and
bssid redacted):

    mwifiex_pcie 0000:01:00.0: info: trying to associate to '&lt;id&gt;' bssid &lt;bssid&gt;
    mwifiex_pcie 0000:01:00.0: info: associated to bssid &lt;bssid&gt; successfully
    mwifiex_pcie 0000:01:00.0: crypto keys added
    mwifiex_pcie 0000:01:00.0: info: successfully disconnected from &lt;bssid&gt;: reason code 3

Tracking down this problem lead to the overflow check introduced by the
aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This
check fails on networks with 256 bit keys due to the current storage
size for AES keys in struct mwifiex_aes_param being only 128 bit.

To fix this issue, increase the storage size for AES keys to 256 bit.

Fixes: e18696786548 ("mwifiex: Prevent memory corruption handling keys")
Signed-off-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Reported-by: Kaloyan Nikolov &lt;konik98@gmail.com&gt;
Tested-by: Kaloyan Nikolov &lt;konik98@gmail.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Tested-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.com
</content>
</entry>
<entry>
<title>mt76: mt7915: use ieee80211_free_txskb to free tx skbs</title>
<updated>2020-08-27T13:13:01Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2020-08-12T14:49:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=b4be5a53ebf478ffcfb4c98c0ccc4a8d922b9a02'/>
<id>urn:sha1:b4be5a53ebf478ffcfb4c98c0ccc4a8d922b9a02</id>
<content type='text'>
Using dev_kfree_skb for tx skbs breaks AQL. This worked until now only
by accident, because a mac80211 issue breaks AQL on drivers with firmware
rate control that report the rate via ieee80211_tx_status_ext as struct
rate_info.

Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Acked-by: Toke Høiland-Jørgensen &lt;toke@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200812144943.91974-1-nbd@nbd.name
</content>
</entry>
<entry>
<title>mt76: mt7615: use v1 MCU API on MT7615 to fix issues with adding/removing stations</title>
<updated>2020-08-27T13:12:19Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@nbd.name</email>
</author>
<published>2020-08-12T10:23:32Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=d1c9da9e4c938e8bbf8b0ef9e5772b97db5639e9'/>
<id>urn:sha1:d1c9da9e4c938e8bbf8b0ef9e5772b97db5639e9</id>
<content type='text'>
The implementation of embedding WTBL update inside the STA_REC update is buggy
on the MT7615 v2 firmware. This leads to connection issues after a station has
connected and disconnected again.

Switch to the v1 MCU API ops, since they have received much more testing and
should be more stable.

On MT7622 and later, the v2 API is more actively used, so we should keep using
it as well.

Fixes: 6849e29ed92e ("mt76: mt7615: add starec operating flow for firmware v2")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau &lt;nbd@nbd.name&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200812102332.11812-1-nbd@nbd.name
</content>
</entry>
<entry>
<title>brcmfmac: reserve tx credit only when txctl is ready to send</title>
<updated>2020-08-18T14:32:22Z</updated>
<author>
<name>Wright Feng</name>
<email>wright.feng@cypress.com</email>
</author>
<published>2020-08-13T07:00:16Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=9a2a0862d973c9eab6a1f3efa0d4d18dcedbaf1a'/>
<id>urn:sha1:9a2a0862d973c9eab6a1f3efa0d4d18dcedbaf1a</id>
<content type='text'>
The 4329 throughput drops from 40.2 Mbits/sec to 190 Kbits/sec in 2G
11n mode because the commit b41c232d33666 ("brcmfmac: reserve 2 credits
for host tx control path"). To fix the issue, host driver only reserves
tx control credit when there is a txctl frame is pending to send. And
we also check available credit by using "not equal to 0" instead of
"greater than 0" because tx_max and tx_seq are circled positive numbers.

Reported-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Fixes: b41c232d33666 ("brcmfmac: reserve 2 credits for host tx control path")
Signed-off-by: Wright Feng &lt;wright.feng@cypress.com&gt;
Tested-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Link: https://lore.kernel.org/r/20200813070017.89023-1-wright.feng@cypress.com
</content>
</entry>
<entry>
<title>rtl818x: constify ioreadX() iomem argument (as in generic implementation)</title>
<updated>2020-08-15T02:56:57Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzk@kernel.org</email>
</author>
<published>2020-08-15T00:32:11Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=5ca6ad7dce2f3d05bd67a15031c750c0214b7b33'/>
<id>urn:sha1:5ca6ad7dce2f3d05bd67a15031c750c0214b7b33</id>
<content type='text'>
The ioreadX() helpers have inconsistent interface.  On some architectures
void *__iomem address argument is a pointer to const, on some not.

Implementations of ioreadX() do not modify the memory under the address so
they can be converted to a "const" version for const-safety and
consistency among architectures.

Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Acked-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Cc: Allen Hubbe &lt;allenbh@gmail.com&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Helge Deller &lt;deller@gmx.de&gt;
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Cc: Jakub Kicinski &lt;kuba@kernel.org&gt;
Cc: "James E.J. Bottomley" &lt;James.Bottomley@HansenPartnership.com&gt;
Cc: Jason Wang &lt;jasowang@redhat.com&gt;
Cc: Jon Mason &lt;jdmason@kudzu.us&gt;
Cc: Matt Turner &lt;mattst88@gmail.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: "Michael S. Tsirkin" &lt;mst@redhat.com&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Rich Felker &lt;dalias@libc.org&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Link: http://lkml.kernel.org/r/20200709072837.5869-3-krzk@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'akpm' (patches from Andrew)</title>
<updated>2020-08-07T18:39:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2020-08-07T18:39:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=81e11336d97e7a4c25a65c302ef2bf9cd9808ed4'/>
<id>urn:sha1:81e11336d97e7a4c25a65c302ef2bf9cd9808ed4</id>
<content type='text'>
Merge misc updates from Andrew Morton:

 - a few MM hotfixes

 - kthread, tools, scripts, ntfs and ocfs2

 - some of MM

Subsystems affected by this patch series: kthread, tools, scripts, ntfs,
ocfs2 and mm (hofixes, pagealloc, slab-generic, slab, slub, kcsan,
debug, pagecache, gup, swap, shmem, memcg, pagemap, mremap, mincore,
sparsemem, vmalloc, kasan, pagealloc, hugetlb and vmscan).

* emailed patches from Andrew Morton &lt;akpm@linux-foundation.org&gt;: (162 commits)
  mm: vmscan: consistent update to pgrefill
  mm/vmscan.c: fix typo
  khugepaged: khugepaged_test_exit() check mmget_still_valid()
  khugepaged: retract_page_tables() remember to test exit
  khugepaged: collapse_pte_mapped_thp() protect the pmd lock
  khugepaged: collapse_pte_mapped_thp() flush the right range
  mm/hugetlb: fix calculation of adjust_range_if_pmd_sharing_possible
  mm: thp: replace HTTP links with HTTPS ones
  mm/page_alloc: fix memalloc_nocma_{save/restore} APIs
  mm/page_alloc.c: skip setting nodemask when we are in interrupt
  mm/page_alloc: fallbacks at most has 3 elements
  mm/page_alloc: silence a KASAN false positive
  mm/page_alloc.c: remove unnecessary end_bitidx for [set|get]_pfnblock_flags_mask()
  mm/page_alloc.c: simplify pageblock bitmap access
  mm/page_alloc.c: extract the common part in pfn_to_bitidx()
  mm/page_alloc.c: replace the definition of NR_MIGRATETYPE_BITS with PB_migratetype_bits
  mm/shuffle: remove dynamic reconfiguration
  mm/memory_hotplug: document why shuffle_zone() is relevant
  mm/page_alloc: remove nr_free_pagecache_pages()
  mm: remove vm_total_pages
  ...
</content>
</entry>
<entry>
<title>mm, treewide: rename kzfree() to kfree_sensitive()</title>
<updated>2020-08-07T18:33:22Z</updated>
<author>
<name>Waiman Long</name>
<email>longman@redhat.com</email>
</author>
<published>2020-08-07T06:18:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kobert.dev/pm24.git/commit/?id=453431a54934d917153c65211b2dabf45562ca88'/>
<id>urn:sha1:453431a54934d917153c65211b2dabf45562ca88</id>
<content type='text'>
As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/kzfree/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

Suggested-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: Waiman Long &lt;longman@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Cc: James Morris &lt;jmorris@namei.org&gt;
Cc: "Serge E. Hallyn" &lt;serge@hallyn.com&gt;
Cc: Joe Perches &lt;joe@perches.com&gt;
Cc: Matthew Wilcox &lt;willy@infradead.org&gt;
Cc: David Rientjes &lt;rientjes@google.com&gt;
Cc: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Cc: "Jason A . Donenfeld" &lt;Jason@zx2c4.com&gt;
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
