[PATCH 2/2] nfc: st21nfca: Remove unnecessary devm_kzalloc() cast

[Fabio Estevam]

From: Fabio Estevam 

There is no need to use cast for the returned value
from memory allocation functions, so remove the unnecessary cast.

Detected via Coccinelle script:
scripts/coccinelle/api/alloc/alloc_cast.cocci.

Signed-off-by: Fabio Estevam 
---
 drivers/nfc/st21nfca/se.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index fd967a3..5b63549 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -326,8 +326,7 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev 
*hdev, u8 host,
skb->data[0] != NFC_EVT_TRANSACTION_AID_TAG)
return -EPROTO;
 
-   transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
-  skb->len - 2, GFP_KERNEL);
+   transaction = devm_kzalloc(dev, skb->len - 2, GFP_KERNEL);
if (!transaction)
return -ENOMEM;
 
-- 
2.7.4

[PATCH 1/2] nfc: st21nfca: Check for devm_kzalloc() failure

[Fabio Estevam]

From: Fabio Estevam 

devm_kzalloc() may fail, so we should better check for error and
propagate the error in the case of allocation failure.

This avoids a potential NULL pointer dereference later on.

Signed-off-by: Fabio Estevam 
---
 drivers/nfc/st21nfca/se.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/nfc/st21nfca/se.c b/drivers/nfc/st21nfca/se.c
index 4bed9e84..fd967a3 100644
--- a/drivers/nfc/st21nfca/se.c
+++ b/drivers/nfc/st21nfca/se.c
@@ -328,6 +328,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev 
*hdev, u8 host,
 
transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
   skb->len - 2, GFP_KERNEL);
+   if (!transaction)
+   return -ENOMEM;
 
transaction->aid_len = skb->data[1];
memcpy(transaction->aid, >data[2],
-- 
2.7.4

Re: [PATCH] mac80211: Fix wlan freezes under load at rekey

[Ben Greear]

On 03/24/2018 03:29 AM, Alexander Wetzel wrote:

Rekeying a pairwise key with encryption offload and only keyid 0 has two
potential races which can freeze the wlan conection till rekeyed again:

 1) For incomming packets:
If the local STA installs the key prior to the remote STA we still
have the old key active in the hardware for a short time after
mac80211 switched to the new key.
The card can still hand over packets decoded with the old key to
mac80211, bumping the new PN (IV) value to an incorrect high number and
tricking the local replay detection to drop all packets really sent
with the new key.

 2) For outgoing packets:
If mac80211 is providing the PN (IV) and hands over the cleartext
packets for encryption to the hardware immediately prior to a key
change the driver/card may process the queued packets after
switching to the new key.
This will immediatelly bump the PN (IV) value on the remote STA to
an incorrect high number, also freezing the connection.

Both issues can be prevented by deleting the key from the hardware prior
to switching to the new key in mac80211, falling back to software
encryption/decryption till the switch to the new key is completed.


What will happen to drivers like ath10k that cannot do software encrypt/decrypt?

ath10k can support multiple key-ids as far as I can tell,
so maybe it would just never hit this code?

Thanks,
Ben



Signed-off-by: Alexander Wetzel 
---
 net/mac80211/key.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index aee05ec3f7ea..266ea0b507e7 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -332,10 +332,15 @@ static void ieee80211_key_replace(struct 
ieee80211_sub_if_data *sdata,

WARN_ON(new && old && new->conf.keyidx != old->conf.keyidx);

-   if (old)
+   if (old) {
idx = old->conf.keyidx;
-   else
+   /* Make sure the card can't encrypt/decrypt packets with
+* the old key prior to switching to new key in mac80211.
+*/
+   ieee80211_key_disable_hw_accel(old);
+   } else {
idx = new->conf.keyidx;
+   }

if (sta) {
if (pairwise) {



--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

[Larry Finger]

On 03/23/2018 11:10 PM, Quytelda Kahja wrote:

It is neater and more consistent with the rest of the document to use the
BIT() macro from 'linux/bitops.h' to define the WLAN_CAPABILITY_*
bitmasks.  In the case of WLAN_CAPABILITY_DMG_TYPE_{IBSS, PBSS, AP},
bitshifting integers by 0 does nothing, so there is no reason to do it in
the code; replace these values with plain integers.

Signed-off-by: Quytelda Kahja 


In the commit message for all of these, what is the "document" to which you 
refer?

I'm not quite sure why you split these changes into 3 parts, but I guess that 
is OK.

Larry

Re: [PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

[Quytelda Kahja]

The "document" refers to the file in which the changes were made
('include/linux/ieee80211.h').

I tend to try to split my commits into the smallest logically related
changes possible, hence the three patch series.  This particular case
may be a little on the extreme side, but if the maintainer desires,
they can always squash them together or ask me to resubmit as one
patch.

On 3/24/18, Larry Finger  wrote:
> On 03/23/2018 11:10 PM, Quytelda Kahja wrote:
>> It is neater and more consistent with the rest of the document to use the
>> BIT() macro from 'linux/bitops.h' to define the WLAN_CAPABILITY_*
>> bitmasks.  In the case of WLAN_CAPABILITY_DMG_TYPE_{IBSS, PBSS, AP},
>> bitshifting integers by 0 does nothing, so there is no reason to do it in
>> the code; replace these values with plain integers.
>>
>> Signed-off-by: Quytelda Kahja 
>
> In the commit message for all of these, what is the "document" to which you
> refer?
>
> I'm not quite sure why you split these changes into 3 parts, but I guess
> that is OK.
>
> Larry
>
-- 
Thank you,
Quytelda Kahja

[PATCH] mac80211: Fix wlan freezes under load at rekey

[Alexander Wetzel]

Rekeying a pairwise key with encryption offload and only keyid 0 has two
potential races which can freeze the wlan conection till rekeyed again:

 1) For incomming packets:
If the local STA installs the key prior to the remote STA we still
have the old key active in the hardware for a short time after
mac80211 switched to the new key.
The card can still hand over packets decoded with the old key to
mac80211, bumping the new PN (IV) value to an incorrect high number and
tricking the local replay detection to drop all packets really sent
with the new key.

 2) For outgoing packets:
If mac80211 is providing the PN (IV) and hands over the cleartext
packets for encryption to the hardware immediately prior to a key
change the driver/card may process the queued packets after
switching to the new key.
This will immediatelly bump the PN (IV) value on the remote STA to
an incorrect high number, also freezing the connection.

Both issues can be prevented by deleting the key from the hardware prior
to switching to the new key in mac80211, falling back to software
encryption/decryption till the switch to the new key is completed.

Signed-off-by: Alexander Wetzel 
---
 net/mac80211/key.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index aee05ec3f7ea..266ea0b507e7 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -332,10 +332,15 @@ static void ieee80211_key_replace(struct 
ieee80211_sub_if_data *sdata,
 
WARN_ON(new && old && new->conf.keyidx != old->conf.keyidx);
 
-   if (old)
+   if (old) {
idx = old->conf.keyidx;
-   else
+   /* Make sure the card can't encrypt/decrypt packets with
+* the old key prior to switching to new key in mac80211.
+*/
+   ieee80211_key_disable_hw_accel(old);
+   } else {
idx = new->conf.keyidx;
+   }
 
if (sta) {
if (pairwise) {
-- 
2.16.2

pull-request: wireless-drivers-next 2018-03-24

[Kalle Valo]

Hi Dave,

here's the first pull request to net-next for 4.17. What's special here
is the addition of a new bluetooth driver, but that's been acked by
Marcel. Also we add a new include file to include/net because of that.

Please let me know if you have any problems.

Kalle

The following changes since commit f74290fdb363665538743d14c4f00aeacdb68d87:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-02-24 
00:04:20 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2018-03-24

for you to fetch changes up to 28bf8312a983a7873997bf3faf4c2b4e62e4abc0:

  mwifiex: get_channel from firmware (2018-03-13 18:53:47 +0200)


wireless-drivers-next patches for 4.17

The biggest changes are the bluetooth related patches to the rsi
driver. It adds a new bluetooth driver which communicates directly
with the wireless driver and the interface is defined in
include/net/rsi_91x.h.

Major changes:

wl1251

* read the MAC address from the NVS file

rtlwifi

* enable mac80211 fast-tx support

mt76

* add capability to select tx/rx antennas

mt7601

* let mac80211 validate rx CCMP Packet Number (PN)

rsi

* bluetooth: add new btrsi driver

* btcoex support with the new btrsi driver


Arend Van Spriel (8):
  brcmfmac: move brcmf_bus_preinit() call just after changing bus state
  brcmfmac: move allocation of control rx buffer to brcmf_sdio_bus_preinit()
  brcmfmac: call brcmf_attach() just before calling brcmf_bus_started()
  brcmfmac: usb: call brcmf_usb_up() during brcmf_bus_preinit()
  brcmfmac: move brcmf_attach() function in core.c
  brcmfmac: remove brcmf_bus_started() from bus api
  brcmfmac: change log level for some low-level sdio functions
  brcmfmac: remove duplicate pointer variable from 
brcmf_sdio_firmware_callback()

Arnd Bergmann (1):
  rtlwifi: rtl8192cu: remove pointless memcpy

Arvind Yadav (1):
  ssb: use put_device() if device_register fail

Colin Ian King (2):
  wireless: zd1211rw: remove redundant assignment of pointer 'q'
  brcmsmac: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR

Denis 'GNUtoo' Carikli (1):
  bcma: add HP Stream Notebook

Ganapathi Bhat (3):
  Revert "mwifiex: fix incorrect ht capability problem"
  mwifiex: fix incorrect ht capability problem
  mwifiex: get_channel from firmware

Gustavo A. R. Silva (1):
  ssb: return boolean instead of integer in ssb_dma_translation_special_bit

Jia-Ju Bai (1):
  bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

Johannes Berg (1):
  brcmfmac: reject too long PSK

Lorenzo Bianconi (11):
  mt76x2: remove warnings in mt76x2_mac_write_txwi()
  mt7601u: move mt7601u_set_macaddr in mac related code
  mt7601u: set device mac address in mt7601u_add_interface()
  mt7601u: make write with mask access atomic
  mt76: initialize available_antennas_{tx,rx} info
  mt76: add mt76_init_stream_cap routine
  mt76x2: add mac80211 {set,get}_antenna callbacks
  mt7601u: remove a warning in mt7601u_efuse_physical_size_check()
  mt76x2: remove unnecessary len variable in mt76x2_eeprom_load()
  mt7601u: simplify mt7601u_mcu_msg_alloc signature
  mt7601u: let mac80211 validate rx CCMP PN

Matt Redfearn (2):
  ssb: Prevent build of PCI host features in module
  bcma: Prevent build of PCI host features in module

Matthias Kaehlcke (1):
  rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

Pali Rohár (4):
  wl1251: Update wl->nvs_len after wl->nvs is valid
  wl1251: Generate random MAC address only if driver does not have valid
  wl1251: Parse and use MAC address from supplied NVS data
  wl1251: Set generated MAC address back to NVS data

Ping-Ke Shih (11):
  rtlwifi: enable mac80211 fast-tx support
  rtlwifi: Add Support VHT to spec_ver
  rtlwifi: Use 6 bits as sequence number of TX report
  rtlwifi: Extend tx_power_by_rate_offset size for newer IC
  rtlwifi: Add rate section and its related definition and comment
  rtlwifi: Fix VHT NSS in RC
  rtlwifi: add definition radio_mask for RF and maximum bandwidth
  rtlwifi: add efuse ops for other components
  rtlwifi: btcoex: add routine to set default port id
  rtlwifi: btcoex: Add 8822be btcoex supported files for wifi only
  rtlwifi: btcoex: fix argument typo of if-statement found by Coccinelle

Prameela Rani Garnepudi (9):
  rsi: add rx control block to handle rx packets in USB
  rsi: add header file rsi_91x
  rsi: add coex support
  Bluetooth: btrsi: add new rsi bluetooth driver
  rsi: add module parameter operating mode
  rsi: sdio changes to support BT
  rsi: improve RX handling in SDIO interface
  rsi: use dynamic RX 

Re: [PATCH] ath9k: introduce endian_check module parameter

[Mathias Kresin]

19.03.2018 09:11, Martin Blumenstingl:

Hello everyone,

On Wed, Mar 14, 2018 at 10:34 PM, Arend van Spriel
 wrote:

+ Martin

On 3/14/2018 3:34 PM, Kalle Valo wrote:


Bas Vermeulen  writes:


--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -67,6 +67,9 @@ static int ath9k_ps_enable;
 module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
 MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
 +static int ath9k_endian_check;
+module_param_named(endian_check, ath9k_endian_check, int, 0444);
+MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness
compatibility");
 #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
   int ath9k_use_chanctx;
@@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
 ether_addr_copy(common->macaddr, mac);
 ah->ah_flags &= ~AH_USE_EEPROM;
-   ah->ah_flags |= AH_NO_EEP_SWAP;
+   if (!ath9k_endian_check)
+   ah->ah_flags |= AH_NO_EEP_SWAP;


A bit annoying to have a module parameter, isn't there any automatic
way
to detect/try this? But on the other hand I guess this isn't a common
problem as nobody has reported this before?



There is an automatic way to detect this, but that is disabled by the
AH_NO_EEP_SWAP flag.



Ah, I didn't check the code at all.


The platform initialisation does not set this flag if the endian_check
member of pdata is set to true, but there is no way to not set this
when using a device tree. I used a module parameter instead of a
device tree variable because I don't know of a way to modify the
device tree my PowerMac boots with.



Ok, makes sense. A module parameter is not an ideal solution I guess
it's ok in this case.


Kalle: Are there any changes you want me to make in order to get this
accepted? I didn't see anything for me to resolve, but I may have
missed something.

I can submit a patch to not set the AH_NO_EEP_SWAP flag by default if
you prefer, as that would fix my problem as well. I am just not sure
that doesn't break things for some platform/device I don't have.



I'm not really sure what to do. Basically this is a choise between bad
for user experience (the module parameter) or risk of regressions
(disable AH_NO_EEP_SWAP by default). As ath9k is used in very exotic
hardware I'm starting to lean towards the module parameter approach
(your patch) but would like to know what others think, especially Felix
(CCed).



Hi Kalle,

Sorry for barging in, but I figured git history might tell us something. The
flag was originally added by Felix (commit a59dadbeeaf7 ("ath9k: add support
for endian swap of eeprom from platform data")) and the function
ath9k_of_init() was added by Martin (CCed):

commit 138b41253d9c9f9a06c8b086880cd3e839a23d69
Author: Martin Blumenstingl 
Date:   Sun Oct 16 22:59:07 2016 +0200

 ath9k: parse the device configuration from an OF node

Maybe he recalls what device(s) needed it.

lots embedded devices (supported by OpenWrt) use ath9k chips

my primary target was the BT HomeHub 5A and some AVM Fritz Box (all
using a lantiq SoC, but there are many more). these typically ship
with:
- a generic ath9k EEPROM which is sometimes even stored on NAND (= not
directly connected to the ath9k chipset), which is why we need the
"qca,no-eeprom"
- some ship with a broken EEPROM that enables the 5GHz band on a
2.4GHz-only card, which is why we need "qca,disable-5ghz"
- some ship with an EEPROM that doesn't have a unique mac address (the
mac address is sometimes also stored on NAND), which is why we support
the "mac-address" property
- some ship an EEPROM where only the magic bytes are swapped (but the
content is not), while others have both (magic bytes and content)
byte-swapped

looking at ath9k_of_init it seems that "ah->ah_flags &=
~AH_USE_EEPROM" and "ah->ah_flags |= AH_NO_EEP_SWAP" are called
unconditionally.
maybe these should be part of the "qca,no-eeprom" if-block a few lines above

I also added Mathias to the CC list
@Mathias: I believe all our .dts files in OpenWrt which specify an
ath9k chipset also set the "qca,no-eeprom" property, right (a quick
check suggests "yes")?


Yes, they all should have the qca,no-eeprom property. If not, it is a 
bug in the OpenWrt dts files.


Mathias

Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure

[kbuild test robot]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nipun-Gupta/dma-mapping-move-dma-configuration-to-bus-infrastructure/20180323-232307
config: score-spct6600_defconfig (attached as .config)
compiler: score-elf-gcc (GCC) 4.9.4
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=score 

All errors (new ones prefixed by >>):

   init/main.o: In function `try_to_run_init_process':
   main.c:(.text+0x40): relocation truncated to fit: R_SCORE_24 against 
`run_init_process'
   main.c:(.text+0x78): relocation truncated to fit: R_SCORE_24 against `.L36'
   init/main.o: In function `.L132':
   main.c:(.text+0x190): relocation truncated to fit: R_SCORE_24 against `.L129'
   main.c:(.text+0x200): relocation truncated to fit: R_SCORE_24 against `.L132'
   init/main.o: In function `loglevel':
   main.c:(.init.text+0xa4): relocation truncated to fit: R_SCORE_24 against 
`get_option'
   init/main.o: In function `.L15':
   main.c:(.init.text+0x110): relocation truncated to fit: R_SCORE_24 against 
`strcmp'
   main.c:(.init.text+0x124): relocation truncated to fit: R_SCORE_24 against 
`parameq'
   main.c:(.init.text+0x14c): relocation truncated to fit: R_SCORE_24 against 
`printk'
   init/main.o: In function `.L31':
   main.c:(.init.text+0x160): relocation truncated to fit: R_SCORE_24 against 
`strcmp'
   init/main.o: In function `.L21':
   main.c:(.init.text+0x170): relocation truncated to fit: R_SCORE_24 against 
`.L15'
   init/main.o: In function `initcall_blacklist':
   main.c:(.init.text+0x198): additional relocation overflows omitted from the 
output
   drivers/base/platform.o: In function `platform_dma_configure':
>> platform.c:(.text.platform_dma_configure+0x0): undefined reference to 
>> `dma_common_configure'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/4] wireless: Use octal not symbolic permissions

[Joe Perches]

On Sat, 2018-03-24 at 12:09 +0200, Kalle Valo wrote:
> Joe Perches  writes:
> > Prefer the direct use of octal for permissions.
[]
> I don't know what tree are you planning to send these to, but I would
> prefer to take this to wireless-drivers-next to minimise any conflicts.

Fine by me.  Done against -next.

pull-request: wireless-drivers 2018-03-24

[Kalle Valo]

Hi Dave,

This is a pull request to the net tree for 4.16. I'm not planning to
send anything more in this cycle for 4.16, unless something really major
comes up.

Please let me know if you have any problems.

Kalle

The following changes since commit 87de1201ddaa39d4f3fafa9f35ac143e582517e6:

  Merge branch 'erspan-fixes' (2018-03-09 13:03:57 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-03-24

for you to fetch changes up to 9b9322db5c5a1917a66c71fe47c3848a9a31227e:

  brcmfmac: Fix check for ISO3166 code (2018-03-20 12:07:58 +0200)


wireless-drivers fixes for 4.16

Some fixes for 4.16, only for iwlwifi and brcmfmac this time. All
pretty small.

iwlwifi

* fix an issue with the multicast queue

* fix IGTK handling

* fix some missing return value checks

* add support for a HW workaround for issues on some platforms

* a couple of fixes for channel-switch

* a few fixes for the aggregation handling code

brcmfmac

* drop Inter-Access Point Protocol packets by default

* fix check for ISO3166 regulatory code


Andrei Otcheretianski (2):
  iwlwifi: mvm: Increase session protection time after CS
  iwlwifi: mvm: Move unused phy's to a default channel

Avraham Stern (3):
  iwlwifi: mvm: clear tx queue id when unreserving aggregation queue
  iwlwifi: mvm: make sure internal station has a valid id
  iwlwifi: mvm: fix array out of bounds reference

Beni Lev (1):
  iwlwifi: mvm: Correctly set IGTK for AP

Emmanuel Grumbach (1):
  iwlwifi: mvm: set the correct tid when we flush the MCAST sta

Johannes Berg (1):
  iwlwifi: mvm: fix error checking for multi/broadcast sta

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2018-03-16' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge tag 'iwlwifi-for-kalle-2018-03-19' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Luca Coelho (1):
  iwlwifi: add shared clock PHY config flag for some devices

Rafał Miłecki (1):
  brcmfmac: drop Inter-Access Point Protocol packets by default

Stefan Wahren (1):
  brcmfmac: Fix check for ISO3166 code

 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  |  5 ++
 .../wireless/broadcom/brcm80211/brcmfmac/common.h  |  1 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 57 +
 drivers/net/wireless/intel/iwlwifi/cfg/9000.c  | 62 ++
 drivers/net/wireless/intel/iwlwifi/fw/file.h   |  1 +
 drivers/net/wireless/intel/iwlwifi/iwl-config.h|  5 ++
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c|  4 ++
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  9 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |  3 +
 drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c  | 21 --
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   | 74 ++
 .../net/wireless/intel/iwlwifi/mvm/time-event.c| 15 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 10 ++-
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  | 38 +--
 15 files changed, 225 insertions(+), 82 deletions(-)

Re: [PATCH] ath9k: Protect queue draining by rcu_read_lock()

[Toke Høiland-Jørgensen]

On 24 March 2018 00:00:39 GMT, Ben Greear  wrote:
>On 02/02/2018 02:36 AM, Toke Høiland-Jørgensen wrote:
>> When ath9k was switched over to use the mac80211 intermediate queues,
>> node cleanup now drains the mac80211 queues. However, this call path
>is
>> not protected by rcu_read_lock() as it was previously entirely
>internal
>> to the driver which uses its own locking.
>
>As far as I can tell, this is not currently in Linus' tree.
>
>Was this dropped on purpose?

It was merged quite recently, but hasn't propagated yet:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next

-Toke