RE: rtl8821ae keep alive not set, connection lost

> -Original Message- > From: linux-wireless-ow...@vger.kernel.org > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf > Of James Cameron > Sent: Thursday, February 01, 2018 2:22 PM > To: Larry Finger > Cc: linux-wireless@vger.kernel.org; Pkshih > Subject: Re: rtl8821ae keep alive

[PATCH] ath10k: Support mgt frame per-chain rssi

From: Ben Greear This provides per-chain rssh for management frames received over wmi. Signed-off-by: Ben Greear --- drivers/net/wireless/ath/ath10k/wmi.c | 21 - drivers/net/wireless/ath/ath10k/wmi.h | 1 + 2 files

Re: lockdep warning in mac80211/tx.c, 4.13.16+ kernel, ath9k related

On 02/01/2018 02:47 PM, Johannes Berg wrote: On Thu, 2018-02-01 at 23:40 +0100, Johannes Berg wrote: The code does a plain rcu_dereference(), no locking other than rcu_read_lock() involved. On second thought though, I'm not convinced that your modifications caused the problem. Given your

Re: lockdep warning in mac80211/tx.c, 4.13.16+ kernel, ath9k related

On Thu, 2018-02-01 at 23:40 +0100, Johannes Berg wrote: > > The code does a plain rcu_dereference(), no locking other than > rcu_read_lock() involved. > > On second thought though, I'm not convinced that your modifications > caused the problem. > > Given your call stack, we'd expect

Re: lockdep warning in mac80211/tx.c, 4.13.16+ kernel, ath9k related

On Thu, 2018-02-01 at 14:33 -0800, Ben Greear wrote: > > All of RCU is suspicious Heh. The code does a plain rcu_dereference(), no locking other than rcu_read_lock() involved. On second thought though, I'm not convinced that your modifications caused the problem. Given your call stack, we'd

Re: lockdep warning in mac80211/tx.c, 4.13.16+ kernel, ath9k related

On 02/01/2018 02:23 PM, Johannes Berg wrote: On Wed, 2018-01-31 at 16:53 -0800, Ben Greear wrote: Any idea why this might be complaining? 30917 Jan 31 15:21:01 2u-6n kernel: = 30918 Jan 31 15:21:01 2u-6n kernel: WARNING: suspicious RCU usage well, that's

Re: lockdep warning in mac80211/tx.c, 4.13.16+ kernel, ath9k related

On Wed, 2018-01-31 at 16:53 -0800, Ben Greear wrote: > > Any idea why this might be complaining? > 30917 Jan 31 15:21:01 2u-6n kernel: = > 30918 Jan 31 15:21:01 2u-6n kernel: WARNING: suspicious RCU usage well, that's why? :-) > 30933

[PATCH] ath5k: remove duplicated re-assignment to pointer 'tq'

From: Colin Ian King Pointer tq is initialized with >ah_txq[queue] and then a few lines later is re-assigned the same value, hence this duplicate assignment is redundant and can be removed. Cleans up clang warning: drivers/net/wireless/ath/ath5k/qcu.c:326:25: warning:

Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware

On 2/1/2018 12:48 PM, Rafał Miłecki wrote: On 2018-01-31 17:14, Hante Meuleman wrote: It is an 802.2 frame, more specifically a LLC XID frames. So why it exists? And more over, why would we crash as an result? Decoding info can be found here:

Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware

On 2018-01-31 17:14, Hante Meuleman wrote: It is an 802.2 frame, more specifically a LLC XID frames. So why it exists? And more over, why would we crash as an result? Decoding info can be found here:

Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware

On 2018-02-01 12:04, Arend van Spriel wrote: On 2/1/2018 11:42 AM, Rafał Miłecki wrote: On 2018-01-31 17:14, Hante Meuleman wrote: It is an 802.2 frame, more specifically a LLC XID frames. So why it exists? And more over, why would we crash as an result? Decoding info can be found here:

Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware

On 2/1/2018 11:42 AM, Rafał Miłecki wrote: On 2018-01-31 17:14, Hante Meuleman wrote: It is an 802.2 frame, more specifically a LLC XID frames. So why it exists? And more over, why would we crash as an result? Decoding info can be found here:

Re: [PATCH] brcmfmac: detect & reject faked packet generated by a firmware

On 2018-01-31 17:14, Hante Meuleman wrote: It is an 802.2 frame, more specifically a LLC XID frames. So why it exists? And more over, why would we crash as an result? Decoding info can be found here:

Re: [RFC v3 0/6] EAPoL over NL80211

Hi, > > [1/6] keep > > [2/6] keep > > [3/6] introduce TX (now patch 5) > > [4/6] introduce RX (now patch 3) > >modify this to require TX from the driver in order to be able to > >set the new flag > > [5/6] add TX to mac80211 > > [6/6] add RX to mac80211 and set the flag > > > >

Re: [4.16,1/4] mt76: implement AP_LINK_PS

Felix Fietkau wrote: > With software A-MPDU reordering in place, frames that notify mac80211 of > powersave changes are reordered as well, which can cause connection > stalls. Fix this by implementing powersave state processing in the > driver. > > Fixes: aee5b8cf2477 ("mt76:

Re: [v5 7/8] rsi: add module parameter operating mode

Marcel Holtmann writes: > Hi Kalle, > >>> Operating mode determines the support for other protocols. >>> This is made as module parameter for better usage. >>> >>> Signed-off-by: Prameela Rani Garnepudi >>> Signed-off-by: Siva Rebbagondla

Re: [v5 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Marcel Holtmann writes: >>> Acked-by: Marcel Holtmann >>> Reviewed-by: Marcel Holtmann >> >> So how should we handle the logistics, should all these go via >> wireless-drivers-next tree or what's the plan? > > I think they should

Re: [v5 7/8] rsi: add module parameter operating mode

Hi Kalle, >> Operating mode determines the support for other protocols. >> This is made as module parameter for better usage. >> >> Signed-off-by: Prameela Rani Garnepudi >> Signed-off-by: Siva Rebbagondla >> Signed-off-by:

Re: [v5 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

Hi Kalle, >>> Redpine bluetooth driver is a thin driver which depends on >>> 'rsi_91x' driver for transmitting and receiving packets >>> to/from device. It creates hci interface when attach() is >>> called from 'rsi_91x' module. >>> >>> Signed-off-by: Prameela Rani Garnepudi