linux-toradex.git/drivers/net/wireless/ath, branch v3.2.33

Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"

2012-10-30T23:26:57+00:00

commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream.

This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.

Signed-off-by: Felix Fietkau 
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: Disable ASPM only for AR9285

2012-10-17T02:48:55+00:00

commit 046b6802c8d3c8a57448485513bf7291633e0fa3 upstream.

Currently, ASPM is disabled for all WLAN+BT combo chipsets
when BTCOEX is enabled. This is incorrect since the workaround
is required only for WB195, which is a AR9285+AR3011 combo
solution. Fix this by checking for the HW version when enabling
the workaround.

Signed-off-by: Sujith Manoharan 
Tested-by: Paul Stewart 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: ath9k_hw_get_btcoex_scheme() function is missing]
Signed-off-by: Ben Hutchings

ath9k: fix decrypt_error initialization in ath_rx_tasklet()

2012-09-12T02:37:00+00:00

commit e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 upstream.

ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
in a loop over the received frames. The decrypt_error flag is
initialized to false
just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
ath9k_rx_skb_preprocess(),
only sets decrypt_error to true and never to false.
Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
decrypt_error to it.
So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
have a leftover value
from another processed frame. In that case, the frame will not be marked with
RX_FLAG_DECRYPTED even if it is decrypted correctly.
When using CCMP encryption this issue can lead to connection stuck
because of CCMP
PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
deciphered frame with ieee80211_aes_ccm_decrypt.
Fix the issue initializing decrypt_error flag at the begging of the
ath_rx_tasklet() loop.

Signed-off-by: Lorenzo Bianconi 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: Add PID/VID support for AR1111

2012-08-19T17:15:29+00:00

commit d4e5979c0da95791aa717c18e162540c7a596360 upstream.

AR1111 is same as AR9485. The h/w
difference between them is quite insignificant,
Felix suggests only very few baseband features
may not be available in AR1111. The h/w code for
AR9485 is already present, so AR1111 should
work fine with the addition of its PID/VID.

Cc: Felix Bitterli 
Reported-by: Tim Bentley 
Signed-off-by: Mohammed Shafi Shajakhan 
Tested-by: Tim Bentley 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: enable serialize_regmode for non-PCIE AR9287

2012-07-12T03:32:02+00:00

commit 7508b657967cf664b5aa0f6367d05016e7e3bc2a upstream.

https://bugzilla.kernel.org/show_bug.cgi?id=42903

Based on the work of 

Signed-off-by: Panayiotis Karabassis 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: fix dynamic WEP related regression

2012-07-12T03:32:01+00:00

commit bed3d9c0b71f9afbfec905cb6db3b9f16be29d4d upstream.

commit 7a532fe7131216a02c81a6c1b1f8632da1195a58
ath9k_hw: fix interpretation of the rx KeyMiss flag

This commit used the rx key miss indication to detect packets that were
passed from the hardware without being decrypted, however it seems that
this bit is not only undefined in the static WEP case, but also for
dynamically allocated WEP keys. This caused a regression when using
WEP-LEAP.

This patch fixes the regression by keeping track of which key indexes
refer to CCMP keys and only using the key miss indication for those.

Reported-by: Stanislaw Gruszka 
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k_hw: avoid possible infinite loop in ar9003_get_pll_sqsum_dvc

2012-07-04T04:44:23+00:00

commit f18e3c6b67f448ec47b3a5b242789bd3d5644879 upstream.

"ath9k: Fix softlockup in AR9485" with commit id
64bc1239c790e051ff677e023435d770d2ffa174 fixed the reported
issue, yet its better to avoid the possible infinite loop
in ar9003_get_pll_sqsum_dvc by having a timeout as suggested
by ath9k maintainers.
http://www.spinics.net/lists/linux-wireless/msg92126.html.
Based on my testing PLL's locking measurement is done in
~200us (2 iterations).

Cc: Rolf Offermanns 
Cc: Sujith Manoharan 
Cc: Senthil Balasubramanian 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: fix a tx rate duration calculation bug

2012-07-04T04:44:21+00:00

commit 76591bea9714a58d8924154068c78d702eb2cb17 upstream.

The rate pointer variable for a rate series is used in a loop before it is
initialized. This went unnoticed because it was used earlier for the RTS/CTS
rate. This bug can lead to the wrong PHY type being passed to the
duration calculation function.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: Fix softlockup in AR9485

2012-07-04T04:44:19+00:00

commit bcb7ad7bcbef030e6ba71ede1f9866368aca7c99 upstream.

steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

	Call Trace:
	[] ? ath_hw_check+0xe0/0xe0 [ath9k]
	[] __const_udelay+0x28/0x30
	[] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
	[] ath_hw_pll_work+0x5b/0xe0 [ath9k]
	[] process_one_work+0x11e/0x470
	[] worker_thread+0x15f/0x360
	[] ? manage_workers+0x230/0x230
	[] kthread+0x93/0xa0
	[] kernel_thread_helper+0x4/0x10
	[] ? kthread_freezable_should_stop+0x70/0x70
	[] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142

Reported-by: Rolf Offermanns 
Tested-by: Mohammed Shafi Shajakhan 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: Fix a WARNING on suspend/resume with IBSS

2012-07-04T04:44:18+00:00

commit 2031b4c2b4904f7448ab9e4bc6b9bf16e32709f5 upstream.

this patch is dependent on the patch "cfg80211: fix interface
combinations"

In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC.  we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.

The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.

        ath: phy0: Cannot create ADHOC interface when other
        interfaces already exist.
        WARNING: at net/mac80211/driver-ops.h:12
        ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
        Hardware name: 2842RK1
        wlan2:  Failed check-sdata-in-driver check, flags: 0x0

        Call Trace:
        [] warn_slowpath_common+0x72/0xa0
        [] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [] warn_slowpath_fmt+0x33/0x40
        [] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
        [] ? mutex_lock_nested+0x23a/0x2f0
        [] ieee80211_resume+0x27/0x70 [mac80211]
        [] wiphy_resume+0x8f/0xa0 [cfg80211]

Cc: Rajkumar Manoharan 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings