[PATCH] wireless: wlcore: spi: remove unnecessary variable

Remove unnecessary variable and refactor the code. Addresses-Coverity-ID: 1365000 Signed-off-by: Gustavo A. R. Silva --- drivers/net/wireless/ti/wlcore/spi.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ti/wlcore/spi.c

Re: Question on setting key right after the EAPOL 4/4 is sent.

Hi Ben, On 06/08/2017 06:43 PM, Ben Greear wrote: On 06/08/2017 04:36 PM, Denis Kenzior wrote: Hi Ben, The problem I see is that sometimes (and quite often when I am using lots of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4 hits the air. When the key is set, the

Re: Question on setting key right after the EAPOL 4/4 is sent.

On 06/08/2017 04:36 PM, Denis Kenzior wrote: Hi Ben, The problem I see is that sometimes (and quite often when I am using lots of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4 hits the air. When the key is set, the NIC will no longer transmit the frame because of

Re: Question on setting key right after the EAPOL 4/4 is sent.

Hi Ben, The problem I see is that sometimes (and quite often when I am using lots of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4 hits the air. When the key is set, the NIC will no longer transmit the frame because of key-length issues in the tx-descriptor (ath10k

Question on setting key right after the EAPOL 4/4 is sent.

I believe I found a problem that may be larger than my little sandbox. The problem I see is that sometimes (and quite often when I am using lots of vdevs and thus the NIC is busy), the keys are set before the EAPOL 4/4 hits the air. When the key is set, the NIC will no longer transmit the frame

[PATCHv5] wlcore: add wl1285 compatible

Motorola Droid 4 uses a WL 1285C. With differences between chips not being public let's add explicit binding for wl1285 instead of relying on wl1283 being very similar. Reviewed-by: Rob Herring Acked-by: Kalle Valo Acked-by: Tony Lindgren

Re: porting 'mwifiex: resolve races between async FW init (failure) and device removal' to kernel 4.1.x

On Thu, Jun 08, 2017 at 01:11:28PM +, Chadzynski, MikolajX wrote: > Races between async firmware initialization and device removal appears on > kernel 4.1.x. > Whole scenario leading to the error together with logs is in > https://bugzilla.kernel.org/show_bug.cgi?id=196003 > Mapping the

Re: [PATCH 1/1] mac80211: ieee80211_rx_napi: remove warning

On 2017-06-07 23:57, Johannes Berg wrote: On Sun, 2017-06-04 at 15:11 +0200, Erik Stromdahl wrote: The softirq count is not always incremented during driver operation. This is the case for usb and sdio network drivers. I'm pretty sure the warning is correct, and we do rely on having

Re: Wifi-Event for when initial 4-way completes?

On 06/08/2017 08:21 AM, Ben Greear wrote: On 06/07/2017 12:25 AM, Wojciech Dubowik wrote: Hello Ben, I have been using this part of wpa_supplicant to notify that 4-Way handshake is completed. around line 868 in wpa_supplicant.c #if defined(CONFIG_CTRL_IFACE) ||

Re: Wifi-Event for when initial 4-way completes?

On 06/07/2017 12:25 AM, Wojciech Dubowik wrote: Hello Ben, I have been using this part of wpa_supplicant to notify that 4-Way handshake is completed. around line 868 in wpa_supplicant.c #if defined(CONFIG_CTRL_IFACE) || !defined(CONFIG_NO_STDOUT_DEBUG) wpa_msg(wpa_s,

Re: [PATCH] mwifiex: Replace semaphore async_sem with mutex

On Thu, Jun 8, 2017 at 12:03 PM, Binoy Jayan wrote: > The semaphore 'async_sem' is used as a simple mutex, so > it should be written as one. Semaphores are going away in the future. > > Signed-off-by: Binoy Jayan > --- > > This patch is part of a

porting 'mwifiex: resolve races between async FW init (failure) and device removal' to kernel 4.1.x

Races between async firmware initialization and device removal appears on kernel 4.1.x. Whole scenario leading to the error together with logs is in https://bugzilla.kernel.org/show_bug.cgi?id=196003 Mapping the patch from kernel 4.11.x "mwifiex: resolve races between async FW init (failure)

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Hi Kalle, On Thu, 08 Jun 2017 15:07:00 +0300 Kalle Valo wrote: > > Stephen Rothwell writes: > > > On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko > > wrote: > >> > >> thanks. As I understand, you've applied this

Re: linux-next: build failure after merge of the wireless-drivers-next tree

Stephen Rothwell writes: > Hi Igor, > > On Wed, 7 Jun 2017 19:43:18 -0700 Igor Mitsyanko > wrote: >> >> thanks. As I understand, you've applied this patch during a merge and no >> further actions are required, correct? > > Dave Miller

[PATCH] mac80211: don't look at the PM bit of BAR frames

When a peer sends a BAR frame with PM bit clear, we should not modify its PM state as madated by the spec in 802.11-20012 10.2.1.2. Signed-off-by: Emmanuel Grumbach --- net/mac80211/rx.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH] mwifiex: Replace semaphore async_sem with mutex

The semaphore 'async_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: Binoy Jayan --- This patch is part of a bigger effort to eliminate unwanted semaphores from the linux kernel.

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

> > On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote: > > Hi, > > Hi, > > > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure > > that we don't index tid_data with this. Hence I think the proper fix is: > > > > diff --git

Re: [PATCH] cfg80211: Fix grammar issue in error message

Please use the driver name as prefix, ie. brcmfmac: iso cfg80211: On 08-06-17 10:01, Martin Michlmayr wrote: > Fix grammar issue in error message about ISO3166. Other than that Acked-by: Arend van Spriel > Signed-off-by: Martin Michlmayr > >

Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)

Am 08.06.2017 um 00:39 schrieb Tobias Diedrich: > Oleksij Rempel wrote: >> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: >>> Oleksij Rempel wrote: Yes, this is "normal" problem. The firmware has no error handler for PCI bus related exceptions. So if we filed to read PCI bus first time,

[PATCH] cfg80211: Fix grammar issue in error message

Fix grammar issue in error message about ISO3166. Signed-off-by: Martin Michlmayr diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index cd1d6730eab7..c1ad81f34658 100644 ---

Re: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

On Thu, Jun 08, 2017 at 06:31:01AM +, Grumbach, Emmanuel wrote: > Hi, Hi, > True, OTOH we need tid to be 8 sometimes. We *just* need to make sure > that we don't index tid_data with this. Hence I think the proper fix is: > > diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c >

RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask

Hi, > Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask > > Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid, > which gives 16 possible values for tid. > This is problematic because IWL_MAX_TID_COUNT is 8, so indexing > iwl_priv::tid_data can