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

ath9k: do not return early to fix rcu unlocking

2017-01-09T07:32:17+00:00

commit d1f1c0e289e1bc46cd6873ba6dd6c627f459e7fa upstream.

Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:

 ===============================
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 -------------------------------
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){......}
 , at:
 [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
  ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
  ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
 Call Trace:
  
  [] dump_stack+0x68/0x93
  [] lockdep_rcu_suspicious+0xd7/0x110
  [] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [] rcu_irq_exit+0x44/0xa0
  [] irq_exit+0x61/0xd0
  [] do_IRQ+0x65/0x110
  [] common_interrupt+0x89/0x89
  
  [] ? cpuidle_enter_state+0x151/0x200
  [] cpuidle_enter+0x12/0x20
  [] call_cpuidle+0x1e/0x40
  [] cpu_startup_entry+0x146/0x220
  [] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann 
Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
Acked-by: Felix Fietkau 
Acked-by: Paul E. McKenney 
Tested-by: Gabriel Craciunescu 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: Really fix LED polarity for some Mini PCI AR9220 MB92 cards.

2017-01-09T07:32:17+00:00

commit 79e57dd113d307a6c74773b8aaecf5442068988a upstream.

The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline. When I was preparing my former commit
0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92
cards.") to fix that I must have somehow messed up with testing, because
I tested the final version of that patch before sending it, and it was
apparently working; but now it is not working on 4.7.6 mainline.

I initially added the PCI_DEVICE_SUB section for 0x0029/0x2096 above the
PCI_VDEVICE section for 0x0029; but then I moved the former below the
latter after seeing how 0x002A sections were sorted in the file.

This turned out to be wrong: if a generic PCI_VDEVICE entry (that has
both subvendor and subdevice IDs set to PCI_ANY_ID) is put before a more
specific one (PCI_DEVICE_SUB), then the generic PCI_VDEVICE entry will
match first and will be used.

With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.

While I'm at it, let's fix 0x002A too by also moving its generic definition
below its specific ones.

Fixes: 0f9edcdd88a9 ("ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.")
Signed-off-by: Vittorio Gambaletta 
[kvalo@qca.qualcomm.com: improve the commit log based on email discussions]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success

2017-01-09T07:32:17+00:00

commit 91851cc7a939039bd401adb6ca3da4402bec1d0c upstream.

Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
changing the return on success from 1 to BIT(gpio). This broke some callers
like ath_is_rfkill_set(). This doesn't fix any known bug in mainline at the
moment, but should be fixed anyway.

Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
return 0 or 1.

Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
Signed-off-by: Matthias Schiffer 
[kvalo@qca.qualcomm.com: mention that doesn't fix any known bug]
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting

2017-01-09T07:32:16+00:00

commit c59f13bbead475096bdfebc7ef59c12e180858de upstream.

The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
8723bu devices not being able to reconnect.

Reported-by: Barry Day 
Signed-off-by: Jes Sorensen 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Fix enter/exit power_save

2017-01-09T07:32:16+00:00

commit ba9f93f82abafe2552eac942ebb11c2df4f8dd7f upstream.

In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
to use work queue"), an error was introduced in the power-save routines
due to the fact that leaving PS was delayed by the use of a work queue.

This problem is fixed by detecting if the enter or leave routines are
in interrupt mode. If so, the workqueue is used to place the request.
If in normal mode, the enter or leave routines are called directly.

Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
Reported-by: Ping-Ke Shih 
Signed-off-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix soft lockup during firmware crash/hw-restart

2017-01-09T07:32:16+00:00

commit c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8 upstream.

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'wireless-drivers-for-davem-2016-11-29' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers

2016-11-30T19:33:44+00:00

Kalle Valo says:

====================
wireless-drivers fixes for 4.9

mwifiex

* properly terminate SSIDs so that uninitalised memory is not printed
====================

Signed-off-by: David S. Miller

mwifiex: printk() overflow with 32-byte SSIDs

2016-11-17T11:16:52+00:00

SSIDs aren't guaranteed to be 0-terminated. Let's cap the max length
when we print them out.

This can be easily noticed by connecting to a network with a 32-octet
SSID:

[ 3903.502925] mwifiex_pcie 0000:01:00.0: info: trying to associate to
'0123456789abcdef0123456789abcdef ' bssid
xx:xx:xx:xx:xx:xx

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris 
Cc: 
Acked-by: Amitkumar Karwar 
Signed-off-by: Kalle Valo

mac80211_hwsim: fix beacon delta calculation

2016-11-15T13:39:56+00:00

Due to the cast from uint32_t to int64_t, a wrong next beacon timing is
calculated and effectively the beacon timer stops working. This is
especially bad for 802.11s mesh networks, because discovery breaks
without beacons.

Signed-off-by: Benjamin Beichler 
Signed-off-by: Johannes Berg

brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap

2016-10-27T15:04:54+00:00

A bugfix added a sanity check around the assignment and use of the
'is_11d' variable, which looks correct to me, but as the function is
rather complex already, this confuses the compiler to the point where
it can no longer figure out if the variable is always initialized
correctly:

brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

This adds an initialization for the newly introduced case in which
the variable should not really be used, in order to make the warning
go away.

Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
Cc: Hante Meuleman 
Cc: Arend van Spriel 
Cc: Kalle Valo 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo