[PATCH] cfg80211: allow vendor commands to be sent to nan interface

From: Andrei Otcheretianski Allow vendor commands that require WIPHY_VENDOR_CMD_NEED_RUNNING flag, to be sent to NAN interface. Signed-off-by: Andrei Otcheretianski Signed-off-by: Luca Coelho ---

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote: > > Annoyingly, all this complication with scatterlists etc is for doing > asynchronous crypto via DMA capable crypto accelerators, and the > networking code (ipsec as well as mac80211, afaik) only allow > synchronous in the first

[PATCHv2 0/2] ath10k: add support for tx bitrate

From: Anilkumar Kolli This patch series adds support for tx bitrate using .sta_statistics callback. tx bitrate tested on QCA4019 using iw. Anilkumar Kolli (2): ath10k: add per peer htt tx stats support for 10.4 ath10k: add support for per sta tx bitrate

[PATCH] wireless: deprecate WDS and disable by default

From: Johannes Berg The old WDS 4-addr frame support is very limited, e.g. * no encryption is possible on such links * it cannot support rate/HT/VHT negotiation * management APIs are very restricted These make the WDS legacy mode useless in practice. All of these

[PATCHv2 0/2] ath10k: add support for tx bitrate

From: Anilkumar Kolli This patch series adds support for tx bitrate using .sta_statistics callback. tx bitrate tested on QCA4019 using iw. Anilkumar Kolli (2): ath10k: add per peer htt tx stats support for 10.4 ath10k: add support for per sta tx bitrate

[PATCHv2 1/2] ath10k: add per peer htt tx stats support for 10.4

From: Anilkumar Kolli Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS' event, Firmware sends one HTT event for every four PPDUs. HTT payload has success pkts/bytes, failed pkts/bytes, retry pkts/bytes and rate info per ppdu. Peer stats are enabled through

[NOT FOR MERGE] ath9k: work around key cache corruption

From: Antonio Quartulli This patch was crafted long time ago to work around a key cache corruption problem on ath9k chipsets. The workaround consists in periodically triggering a worker that uploads all the keys to the HW cache. The worker is triggered also when the vif

[PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4

From: Anilkumar Kolli Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS' event, Firmware sends one HTT event for every four PPDUs. HTT payload has success pkts/bytes, failed pkts/bytes, retry pkts/bytes and rate info per ppdu. Peer stats are enabled through

[PATCHv2 0/2] ath10k: add support for tx bitrate

From: Anilkumar Kolli This patch series adds support for tx bitrate using .sta_statistics callback. tx bitrate tested on QCA4019 using iw. Anilkumar Kolli (2): ath10k: add per peer htt tx stats support for 10.4 ath10k: add support for per sta tx bitrate

Re: sequence diagrams in rst documentation

Am 18.10.2016 um 13:43 schrieb Johannes Berg : > On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote: >>> >>> >>> Related question: I have some sequence diagrams, and just found the >>> seqdiag sphinx plugin. How should we manage adding extensions? Or >>> would

sequence diagrams in rst documentation

On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote: > > > > > > Related question: I have some sequence diagrams, and just found the > > seqdiag sphinx plugin. How should we manage adding extensions? Or > > would you prefer not to add any at all? > > Example here: >

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On 18 October 2016 at 15:16, Johannes Berg wrote: > On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote: >> >> + aead_req = *this_cpu_ptr(ccmp->reqs); >> + if (!aead_req) { >> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC); >> +

[RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data

As a prepatory change to allow per CPU caching of request structures, refactor the key allocation routine so we can access per key data beyond the core AEAD transform easily. Signed-off-by: Ard Biesheuvel --- net/mac80211/aes_ccm.c | 35 +++-

[RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU

This RFC implements per CPU caching of AEAD request structures, which allows us to get rid of the per-packet kzalloc/kzfree calls we were forced to introduce to deal with SG API violations, both in the mac80211 and in the core crypto API code. Since mac80211 only executes the AEAD transforms in

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On 18 October 2016 at 15:24, Johannes Berg wrote: > On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >> >> > Hmm. Is it really worth having a per-CPU variable for each possible >> > key? You could have a large number of those (typically three when >> > you're a

Re: sequence diagrams in rst documentation

On Tue, 18 Oct 2016, Johannes Berg wrote: > On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote: >> Here are my thoughts ... >> >> Every extension which is not a part of the sphinx distro brings new >> external dependencies > > I agree. > >> and the development of

Re: sequence diagrams in rst documentation

On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote: > Here are my thoughts ... > > Every extension which is not a part of the sphinx distro brings new > external dependencies I agree. > and the development of such extensions is IMO > far of kernel development's scope. Arguably, having

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >  > > Hmm. Is it really worth having a per-CPU variable for each possible > > key? You could have a large number of those (typically three when > > you're a client on an AP, and 1 + 1 for each client when you're the > > AP). 2 + 1 for each

[RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

Now that we can no longer invoke AEAD transforms with the aead_request structure allocated on the stack, we perform a kmalloc/kfree for every packet, which is expensive. Since the CCMP routines execute in softirq context, we know there can never be more than one request in flight on each CPU, and

Re: pull-request: mac80211 2016-10-18

From: Johannes Berg Date: Tue, 18 Oct 2016 09:00:57 +0200 > As I mention in the tag message, the most urgent fix here is for > the VMAP_STACK vs. software crypto usage. I ended up applying Ard's > fix that dynamically allocates everything in one go, perhaps we'll >

Re: Intel 7260 not working on 4.4.24 / armv7

On Tue, 2016-10-18 at 18:22 +0200, Oliver Zemann wrote: > Because of the problems with the ath10 card, i bought an intel 7260  > (mpcie) wifi card. Unfortunately it is also not working. > I get tons of those messages: > > [  175.777030] usb 1-1: new full-speed USB device number 2 using >

Re: sequence diagrams in rst documentation

> This could probably be argued either way... Yeah, I guess it could :) > My view has been all along that we should prefer to use existing > extensions written and maintained by others. Perhaps we (the kind of > royal "we" of which I'm personally really not part of) could take on >

Re: Intel 7260 not working on 4.4.24 / armv7

I tried 2 of those wifi cards. Both behaved the same. Also on another clearfog pro. So i guess this is not a hardware fault. Also, the compex WLE600 works (unfortunately the WLE900 does not). Am 18.10.2016 um 21:30 schrieb Emmanuel Grumbach: On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann

Re: Intel 7260 not working on 4.4.24 / armv7

On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann wrote: > Because of the problems with the ath10 card, i bought an intel 7260 (mpcie) > wifi card. Unfortunately it is also not working. > I get tons of those messages: > > [ 175.777030] usb 1-1: new full-speed USB device

[PATCH 2/7] mac80211: fix tid_agg_rx NULL dereference

From: Johannes Berg On drivers setting the SUPPORTS_REORDERING_BUFFER hardware flag, we crash when the peer sends an AddBA request while we already have a session open on the seame TID; this is because on those drivers, the tid_agg_rx is left NULL even though the session

Re: Intel 7260 not working on 4.4.24 / armv7

On Tue, 2016-10-18 at 21:44 +0200, Oliver Zemann wrote: > Is there some way to disable the bluetooth functionality? > Not that I know of. It's kinda pointless though since you then wouldn't have any functionality anyway? I don't have the board you mentioned to Emmanuel, but I can try the 7260

[PATCH 6/7] mac80211: uapsd_queues is in QoS IE order

From: Emmanuel Grumbach The uapsd_queue field is in QoS IE order and not in IEEE80211_AC_*'s order. This means that mac80211 would get confused between BK and BE which is certainly not such a big deal but needs to be fixed. Signed-off-by: Emmanuel Grumbach

[PATCH 5/7] mac80211: add a HW flag for supporting HW TX fragmentation

From: Sara Sharon Currently mac80211 determines whether HW does fragmentation by checking whether the set_frag_threshold callback is set or not. However, some drivers may want to set the HW fragmentation capability depending on HW generation. Allow this by checking a HW

[PATCH 1/7] wireless: radiotap: fix timestamp sampling position values

From: Johannes Berg The values don't match the radiotap spec, corrected that. Reported-by: Oz Shalev Signed-off-by: Johannes Berg --- include/net/ieee80211_radiotap.h | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH 0/7] patches for mac80211/cfg80211 2016-10-18

From: Luca Coelho Hi Johannes, Here are a few patches for mac80211/cfg80211 from our internal tree. You're probably familiar with most of them, I'm just adding a cover letter to make it easier for you to reply "Applied all" (hopefully).:) Cheers, Luca. Emmanuel

[PATCH 4/7] mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger

From: Emmanuel Grumbach iwlwifi will check internally that the tid maps to an AC that is trigger enabled, but can't know what tid exactly. Allow the driver to pass a generic tid and make mac80211 assume that a trigger frame was received. Signed-off-by: Emmanuel

Re: [PATCH -next] cfg80211: fix possible memory leak in cfg80211_iter_combinations()

On Mon, 2016-10-17 at 15:25 +, Wei Yongjun wrote: > From: Wei Yongjun > > 'limits' is malloced in cfg80211_iter_combinations() and should be > freed > before leaving from the error handling cases, otherwise it will cause > memory leak. Yep, thanks; applied. johannes

[PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

- set max_mtu in wil6210 driver - set max_mtu in atmel driver - set min/max_mtu in cisco airo driver, remove airo_change_mtu - set min/max_mtu in ipw2100/ipw2200 drivers, remove libipw_change_mtu - set min/max_mtu in p80211netdev, remove wlan_change_mtu CC: net...@vger.kernel.org CC:

Re: sequence diagrams in rst documentation

On Tue, 18 Oct 2016 13:43:41 +0200 Johannes Berg wrote: > > Example here: > > https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow > > > > Coming back to this - sadly, it appears that this software (blockdiag, > seqdiag) is completely