linux-stable.git/drivers/net/wireless/ath, branch linux-4.5.y

ath5k: Change led pin configuration for compaq c700 laptop

2016-06-08T01:18:48+00:00

commit 7b9bc799a445aea95f64f15e0083cb19b5789abe upstream.

BugLink: http://bugs.launchpad.net/bugs/972604

Commit 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin
configuration for compaq c700 laptop") added a pin configuration for the Compaq
c700 laptop.  However, the polarity of the led pin is reversed.  It should be
red for wifi off and blue for wifi on, but it is the opposite.  This bug was
reported in the following bug report:
http://pad.lv/972604

Fixes: 09c9bae26b0d3c9472cb6ae45010460a2cee8b8d ("ath5k: add led pin configuration for compaq c700 laptop")
Signed-off-by: Joseph Salisbury 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix kernel panic, move arvifs list head init before htt init

2016-06-08T01:18:48+00:00

commit 4ad24a9d83bd4bf0a85e95bf144e18d3fda4fbf1 upstream.

It is observed that while loading and unloading ath10k modules
in an infinite loop, before ath10k_core_start() completion HTT
rx frames are received, while processing these frames,
dereferencing the arvifs list code is getting hit before
initilizing the arvifs list, causing a kernel panic.

This patch initilizes the arvifs list before initilizing htt.

Fixes the below issue:
 [] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 [ath10k_core])
 [] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core])
 [] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core])
 [] (ath10k_htt_txrx_compl_task [ath10k_core])
 [] (tasklet_action+0x8c/0xec)
 [] (tasklet_action)
 [] (__do_softirq+0xf8/0x228)
 [] (__do_softirq)  [] (run_ksoftirqd+0x30/0x90)
 Code: e5954ad8 e2899008 e1540009 0a00000d (e5943008)
 ---[ end trace 71de5c2e011dbf56 ]---
 Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 500ff9f9389d ("ath10k: implement chanctx API")
Signed-off-by: Anilkumar Kolli 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix rx_channel during hw reconfigure

2016-06-08T01:18:48+00:00

commit 1ce8c1484e80010a6e4b9611c65668ff77556f45 upstream.

Upon firmware assert, restart work will be triggered so that mac80211
will reconfigure the driver. An issue is reported that after restart
work, survey dump data do not contain in-use (SURVEY_INFO_IN_USE) info
for operating channel. During reconfigure, since mac80211 already has
valid channel context for given radio, channel context iteration return
num_chanctx > 0. Hence rx_channel is always NULL. Fix this by assigning
channel context to rx_channel when driver restart is in progress.

Signed-off-by: Rajkumar Manoharan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix firmware assert in monitor mode

2016-06-08T01:18:48+00:00

commit 8a75fc54745fd3ce9062ab1cc6429a9da9ac2a68 upstream.

commit 166de3f1895d ("ath10k: remove supported chain mask") had revealed
an issue on monitor mode. Configuring NSS upon monitor interface
creation is causing target assert in all qca9888x and qca6174 firmware.
Firmware assert issue can be reproduced by below sequence even after
reverting commit 166de3f1895d ("ath10k: remove supported chain mask").

ip link set wlan0 down
iw wlan0 set type monitor
iw phy0 set antenna 7
ip link set wlan0 up

This issue is originally reported on qca9888 with 10.1 firmware.

Fixes: 5572a95b4b ("ath10k: apply chainmask settings to vdev on creation")
Reported-by: Janusz Dziedzic 
Signed-off-by: Rajkumar Manoharan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix debugfs pktlog_filter write

2016-06-08T01:18:48+00:00

commit 9ddc486aa09a3413a6c492fcf160ce61bfccb7b1 upstream.

It is observed that, we are disabling the packet log if we write same
value to the pktlog_filter for the second time. Always enable pktlogs
on non zero filter.

Fixes: 90174455ae05 ("ath10k: add support to configure pktlog filter")
Signed-off-by: Anilkumar Kolli 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

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

2016-06-08T01:18:48+00:00

commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.

The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).

The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: Add a module parameter to invert LED polarity.

2016-06-08T01:18:48+00:00

commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream.

The LED can be active high instead of active low on some hardware.

Add the led_active_high module parameter. It defaults to -1 to obey
platform data as before.

Setting the parameter to 1 or 0 will force the LED respectively
active high or active low.

Cc: 
Cc: 
Cc: 
Signed-off-by: Vittorio Gambaletta 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation

2016-05-11T09:21:30+00:00

commit de478a61389cacafe94dc8b035081b681b878f9d upstream.

by moving common code to ar5008_hw_cmn_spur_mitigate i forgot to move
mask_m & mask_p initialisation. This coused a performance regression
on ar9281.

Fixes: f911085ffa88 ("ath9k: split ar5008_hw_spur_mitigate and reuse common code in ar9002_hw_spur_mitigate.")
Reported-by: Gustav Frederiksen 
Tested-by: Gustav Frederiksen 
Signed-off-by: Oleksij Rempel 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath10k: fix pktlog in QCA99X0

2016-05-11T09:21:27+00:00

commit 53a5c9bc53ce51f65699a43c67ab167436d28083 upstream.

Currently, we are providing wrong payload data of pktlog to trace points.
Data we receive from FW through copy engine 8 contains pktlog data alone.
We don't need to parse anything in driver before handing it to trace
points.

Fixes: afb0bf7f530b ("ath10k: add support for pktlog in QCA99X0")
Signed-off-by: Ashok Raj Nagarajan 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix buffer overrun for ar9287

2016-04-20T06:45:13+00:00

[ Upstream commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5 ]

Code that was added back in 2.6.38 has an obvious overflow
when accessing a static array, and at the time it was added
only a code comment was put in front of it as a reminder
to have it reviewed properly.

This has not happened, but gcc-6 now points to the specific
overflow:

drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
     maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
                   ~~~~~~~~~~~~~~~~~~~~~~~~~^~~

It turns out that the correct array length exists in the local
'intercepts' variable of this function, so we can just use that
instead of hardcoding '4', so this patch changes all three
instances to use that variable. The other two instances were
already correct, but it's more consistent this way.

Signed-off-by: Arnd Bergmann 
Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman