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

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

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

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 ---

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

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

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

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,

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

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

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

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

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

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

Re: [PATCH] ath9k: introduce endian_check module parameter

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 +++

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

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:

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

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.

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

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:

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

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