linux.git/drivers/net/wireless/ath, branch v4.0 Linux kernel source tree ath9k: disable TPC support again (for now) 2015-03-16T06:35:23+00:00 Felix Fietkau nbd@openwrt.org 2015-03-15T07:07:04+00:00 c09396eb8e5a8df668174993c6400763022b2466 TPC support has been observed to cause some tx power fluctuations on some devices with at least AR934x and AR938x chips. Disable it for now until the bugs have been found and fixed Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
TPC support has been observed to cause some tx power fluctuations on
some devices with at least AR934x and AR938x chips.
Disable it for now until the bugs have been found and fixed

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath9k: fix tracking of enabled AP beacons 2015-03-16T06:34:36+00:00 Felix Fietkau nbd@openwrt.org 2015-03-12T16:17:18+00:00 1cf48f22c98ae24a49a3f1b6900e4c9a9a0fcc62 sc->nbcnvifs tracks assigned beacon slots, not enabled beacons. Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool) should be updated, or if beacons have been enabled already. With the current code (depending on the order of calls), beacons often do not get enabled in an AP+STA setup. To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a bitmask of enabled beacon slots. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
sc->nbcnvifs tracks assigned beacon slots, not enabled beacons.
Therefore, it cannot be used to decide if cur_conf->enable_beacon (bool)
should be updated, or if beacons have been enabled already.
With the current code (depending on the order of calls), beacons often
do not get enabled in an AP+STA setup.
To fix tracking of enabled beacons, convert cur_conf->enable_beacon to a
bitmask of enabled beacon slots.

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wireless: use %*pb[l] to print bitmaps including cpumasks and nodemasks 2015-02-14T05:21:38+00:00 Tejun Heo tj@kernel.org 2015-02-13T22:37:45+00:00 898600380ccdc5de24e3a1fea2537df41e43fa87 printk and friends can now format bitmaps using '%*pb[l]'. cpumask and nodemask also provide cpumask_pr_args() and nodemask_pr_args() respectively which can be used to generate the two printf arguments necessary to format the specified cpu/nodemask. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: "John W. Linville" <linville@tuxdriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
printk and friends can now format bitmaps using '%*pb[l]'.  cpumask
and nodemask also provide cpumask_pr_args() and nodemask_pr_args()
respectively which can be used to generate the two printf arguments
necessary to format the specified cpu/nodemask.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge tag 'wireless-drivers-next-for-davem-2015-02-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next 2015-02-09T20:13:58+00:00 David S. Miller davem@davemloft.net 2015-02-09T20:07:20+00:00 c8ac18f2006b2926ce375c01646b2f487d1c33b2 Major changes: iwlwifi: * more work for new devices (4165 / 8260) * cleanups / improvemnts in rate control * fixes for TDLS * major statistics work from Johannes - more to come * improvements for the fw error dump infrastructure * usual amount of small fixes here and there (scan, D0i3 etc...) * add support for beamforming * enable stuck queue detection for iwlmvm * a few fixes for EBS scan * fixes for various failure paths * improvements for TDLS Offchannel wil6210: * performance tuning * some AP features brcm80211: * rework some code in SDIO part of the brcmfmac driver related to suspend/resume that were found doing stress testing * in PCIe part scheduling of worker thread needed to be relaxed * minor fixes and exposing firmware revision information to user-space, ie. ethtool. mwifiex: * enhancements for change virtual interface handling * remove coupling between netdev and FW supported interface combination, now conversion from any type of supported interface types to any other type is possible * DFS support in AP mode ath9k: * fix calibration issues on some boards * Wake-on-WLAN improvements ath10k: * add support for qca6174 hardware * enable RX batching to reduce CPU load Conflicts: drivers/net/wireless/rtlwifi/pci.c Conflict resolution is to get rid of the 'end' label and keep the rest. Signed-off-by: David S. Miller <davem@davemloft.net> 
Major changes:

iwlwifi:

* more work for new devices (4165 / 8260)
* cleanups / improvemnts in rate control
* fixes for TDLS
* major statistics work from Johannes - more to come
* improvements for the fw error dump infrastructure
* usual amount of small fixes here and there (scan, D0i3 etc...)
* add support for beamforming
* enable stuck queue detection for iwlmvm
* a few fixes for EBS scan
* fixes for various failure paths
* improvements for TDLS Offchannel

wil6210:

* performance tuning
* some AP features

brcm80211:

* rework some code in SDIO part of the brcmfmac driver related to
  suspend/resume that were found doing stress testing
* in PCIe part scheduling of worker thread needed to be relaxed
* minor fixes and exposing firmware revision information to
  user-space, ie. ethtool.

mwifiex:

* enhancements for change virtual interface handling
* remove coupling between netdev and FW supported interface
  combination, now conversion from any type of supported interface
  types to any other type is possible
* DFS support in AP mode

ath9k:

* fix calibration issues on some boards
* Wake-on-WLAN improvements

ath10k:

* add support for qca6174 hardware
* enable RX batching to reduce CPU load

Conflicts:
	drivers/net/wireless/rtlwifi/pci.c

Conflict resolution is to get rid of the 'end' label and keep
the rest.

Signed-off-by: David S. Miller <davem@davemloft.net>
Merge ath-next from ath.git 2015-02-06T14:14:11+00:00 Kalle Valo kvalo@codeaurora.org 2015-02-06T14:14:11+00:00 d53071143aa5a7cb37cf7db8101042e700b5413f Major changes in ath10k: * add support for qca6174 hardware * enable RX batching to reduce CPU load 
Major changes in ath10k:

* add support for qca6174 hardware
* enable RX batching to reduce CPU load
ath9k: Delete an unnecessary check before the function call "relay_close" 2015-02-06T06:49:22+00:00 Markus Elfring elfring@users.sourceforge.net 2015-02-04T17:48:28+00:00 c0420ea0b598021302b1e1f0f28d621f93968e5d The relay_close() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
The relay_close() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath5k: fix spontaneus AR5312 freezes 2015-02-06T06:42:32+00:00 Sergey Ryazanov ryazanov.s.a@gmail.com 2015-02-03T21:21:13+00:00 8bfae4f9938b6c1f033a5159febe97e441d6d526 Sometimes while CPU have some load and ath5k doing the wireless interface reset the whole WiSoC completely freezes. Set of tests shows that using atomic delay function while we wait interface reset helps to avoid such freezes. The easiest way to reproduce this issue: create a station interface, start continous scan with wpa_supplicant and load CPU by something. Or just create multiple station interfaces and put them all in continous scan. This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use usleep_range where possible"), which replaces initial udelay() by usleep_range(). I do not know actual source of this issue, but all looks like that HW freeze is caused by transaction on internal SoC bus, while wireless block is in reset state. Also I should note that I do not know how many chips are affected, but I did not see this issue with chips, other than AR5312. CC: Jiri Slaby <jirislaby@gmail.com> CC: Nick Kossifidis <mickflemm@gmail.com> CC: Luis R. Rodriguez <mcgrof@do-not-panic.com> Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible") Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com> Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com> Tested-by: Eric Bree <ebree@nltinc.com> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.

The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.

This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().

I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.

Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.

CC: Jiri Slaby <jirislaby@gmail.com>
CC: Nick Kossifidis <mickflemm@gmail.com>
CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
Tested-by: Eric Bree <ebree@nltinc.com>
Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath9k: Choose correct rate for 2GHz channel 2015-02-06T06:39:42+00:00 Sujith Manoharan c_manoha@qca.qualcomm.com 2015-02-02T12:51:13+00:00 c20bbda32a1f5b8293abae9bc39ad964d017afea Set the transmit rate for the keep-alive frames as 1M/CCK when the current channel is in the 2GHz band. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
Set the transmit rate for the keep-alive frames
as 1M/CCK when the current channel is in the
2GHz band.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath9k: Clear TSF2 properly 2015-02-06T06:39:37+00:00 Sujith Manoharan c_manoha@qca.qualcomm.com 2015-02-02T12:51:12+00:00 23ee7c33aa7caae5985a919e597ba2e355d540ea Chips in the AR9003 family have a second TSF, which needs to be cleared when putting the card to sleep. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
Chips in the AR9003 family have a second TSF, which
needs to be cleared when putting the card to
sleep.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
ath9k: Program AR_WA correctly 2015-02-06T06:39:32+00:00 Sujith Manoharan c_manoha@qca.qualcomm.com 2015-02-02T12:51:11+00:00 b6f68b1ecbffc0aec1704c731c3b99acbe3becfd Setting the required configuration in the PCIE WorkAround register needs to be done after all the WoW parameters have been set. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> 
Setting the required configuration in the PCIE
WorkAround register needs to be done after all the
WoW parameters have been set.

Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>