linux-stable.git/drivers/net/wireless, branch v4.7.6

iwlwifi: mvm: update TX queue before making a copy of the skb

2016-09-30T08:12:46+00:00

commit 54c5ef2e93ea002dc5dd63349298b2778fe59edb upstream.

Off-channel action frames (such as ANQP frames) must be sent either on
the AUX queue or on the offchannel queue, otherwise the firmware will
cause a SYSASSERT.

In the current implementation, the queue to be used is correctly set in
the original skb, but this is done after it is copied.  Thus the copy
remains with the original, incorrect queue.

Fix this by setting the queue in the original skb before copying it.

Fixes: commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU len")
Signed-off-by: Beni Lev 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlegacy: avoid warning about missing braces

2016-09-24T08:09:41+00:00

commit 2cce76c3fab410520610a7d2f52faebc3cfcf843 upstream.

gcc-6 warns about code in il3945_hw_txq_ctx_free() being
somewhat ambiguous:

drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]

This adds a set of curly braces to avoid the warning.

Signed-off-by: Arnd Bergmann 
Acked-by: Stanislaw Gruszka 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: bring back direction setting in ath9k_{start_stop}

2016-09-24T08:09:35+00:00

commit e34f2ff40e0339f6a379e1ecf49e8f2759056453 upstream.

A regression was introduced in commit id 79d4db1214a ("ath9k: cleanup
led_pin initial") that broken the WLAN status led on my laptop with
AR9287 after suspending and resuming.

Steps to reproduce:
* Suspend (laptop)
* Resume (laptop)
* Observe that the WLAN led no longer turns ON/OFF depending on the
  status and is always red

Even though for my case it only needs to be set to OUT in ath9k_start
but for consistency bring back the IN direction setting as well.

Fixes: 79d4db1214a0 ("ath9k: cleanup led_pin initial")
Cc: Miaoqing Pan 
Cc: Kalle Valo 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=151711
Signed-off-by: Giedrius Statkevičius 
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix using sta->drv_priv before initializing it

2016-09-24T08:09:35+00:00

commit 7711aaf08ad3fc4d0e937eec1de0a63620444ce7 upstream.

A station pointer can be passed to the driver on tx, before it has been
marked as associated. Since ath9k_sta_state was initializing the entry
too late, it resulted in some spurious crashes.

Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback")
Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

2016-09-24T08:09:35+00:00

commit ded89912156b1a47d940a0c954c43afbabd0c42c upstream.

User-space can choose to omit NL80211_ATTR_SSID and only provide raw
IE TLV data. When doing so it can provide SSID IE with length exceeding
the allowed size. The driver further processes this IE copying it
into a local variable without checking the length. Hence stack can be
corrupted and used as exploit.

Reported-by: Daxing Guo 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: restore stopping netdev queue when bus clogs up

2016-08-20T16:10:53+00:00

commit 82bc9ab6a8f577d2174a736c33f3d4ecf7d9ef47 upstream.

When the host-interface bus has hard time handling transmit packets
it informs higher layer about this and it would stop the netdev
queue when needed. However, since commit 9cd18359d31e ("brcmfmac:
Make FWS queueing configurable.") this was broken. With this patch
the behaviour is restored.

Fixes: 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.")
Tested-by: Per Förlin 
Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add new 8265

2016-08-20T16:10:53+00:00

commit f24bbae565d279cd90c904fe55b539a45631705e upstream.

Add 6 new 8265 series PCI IDs:
  - (0x24FD, 0x1130)
  - (0x24FD, 0x0130)
  - (0x24FD, 0x0910)
  - (0x24FD, 0x0930)
  - (0x24FD, 0x0950)
  - (0x24FD, 0x0850)

Signed-off-by: Oren Givon 
Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: add new 8260 PCI IDs

2016-08-20T16:10:53+00:00

commit 4b79deece5d45396422d469afa11f9d69ccb3d8b upstream.

Add 3 new 8260 series PCI IDs:
  - (0x24F3, 0x10B0)
  - (0x24F3, 0xD0B0)
  - (0x24F3, 0xB0B0)

Signed-off-by: Oren Givon 
Signed-off-by: David Spinadel 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: fix a race in firmware loading flow

2016-08-20T16:10:53+00:00

commit f16c3ebfa64fdf0e2dc88e6baa72da95ab70ffd7 upstream.

Upon firmware load interrupt (FH_TX), the ISR re-enables the
firmware load interrupt only to avoid races with other
flows as described in the commit below. When the firmware
is completely loaded, the thread that is loading the
firmware will enable all the interrupts to make sure that
the driver gets the ALIVE interrupt.
The problem with that is that the thread that is loading
the firmware is actually racing against the ISR and we can
get to the following situation:

CPU0					CPU1
iwl_pcie_load_given_ucode
	...
	iwl_pcie_load_firmware_chunk
		wait_for_interrupt
					
					ISR handles CSR_INT_BIT_FH_TX
					ISR wakes up the thread on CPU0
	/* enable all the interrupts
	 * to get the ALIVE interrupt
	 */
	iwl_enable_interrupts
					ISR re-enables CSR_INT_BIT_FH_TX only
	/* start the firmware */
	iwl_write32(trans, CSR_RESET, 0);

BUG! ALIVE interrupt will never arrive since it has been
masked by CPU1.

In order to fix that, change the ISR to first check if
STATUS_INT_ENABLED is set. If so, re-enable all the
interrupts. If STATUS_INT_ENABLED is clear, then we can
check what specific interrupt happened and re-enable only
that specific interrupt (RFKILL or FH_TX).

All the credit for the analysis goes to Kirtika who did the
actual debugging work.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: pcie: enable interrupts before releasing the NIC's CPU

2016-08-20T16:10:53+00:00

commit 2aabdbdc17b7c53490337bfc58de3409c84d85d2 upstream.

The NIC's CPU gets started after the firmware has been
written to its memory. The first thing it does is to
send an interrupt to let the driver know that it is
running. In order to get that interrupt, the driver needs
to make sure it is not masked. Of course, the interrupt
needs to be enabled in the driver before the CPU starts to
run.
I mistakenly inversed those two steps leading to races
which prevented the driver from getting the alive interrupt
from the firmware.
Fix that.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
Signed-off-by: Greg Kroah-Hartman