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

rt2x00: fix random stalls

2012-03-19T16:02:19+00:00

commit 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 upstream.

Is possible that we stop queue and then do not wake up it again,
especially when packets are transmitted fast. That can be easily
reproduced with modified tx queue entry_num to some small value e.g. 16.

If mac80211 already hold local->queue_stop_reason_lock, then we can wait
on that lock in both rt2x00queue_pause_queue() and
rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
is possible that __ieee80211_wake_queue() will be performed before
__ieee80211_stop_queue(), hence we stop queue and newer wake up it
again.

Another race condition is possible when between rt2x00queue_threshold()
check and rt2x00queue_pause_queue() we will process all pending tx
buffers on different cpu. This might happen if for example interrupt
will be triggered on cpu performing rt2x00mac_tx().

To prevent race conditions serialize pause/unpause by queue->tx_lock.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

carl9170: fix frame delivery if sta is in powersave mode

2012-03-12T19:31:40+00:00

commit 9926a67557532acb6cddb1c1add02952175b5c72 upstream.

Nicolas Cavallari discovered that carl9170 has some
serious problems delivering data to sleeping stations.

It turns out that the driver was not honoring two
important flags (IEEE80211_TX_CTL_POLL_RESPONSE and
IEEE80211_TX_CTL_CLEAR_PS_FILT) which are set on
frames that should be sent although the receiving
station is still in powersave mode.

Reported-by: Nicolas Cavallari 
Signed-off-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

carl9170: Fix memory accounting when sta is in power-save mode.

2012-03-12T19:31:40+00:00

commit 992d52529d7840236d3059b51c15d5eb9e81a869 upstream.

On Access Point mode, when transmitting a packet, if the destination
station is in powersave mode, we abort transmitting the packet to the
device queue, but we do not reclaim the allocated memory.  Given enough
packets, we can go in a state where there is no packet on the device
queue, but we think the device has no memory left, so no packet gets
transmitted, connections breaks and the AP stops working.

This undo the allocation done in the TX path when the station is in
power-save mode.

Signed-off-by: Nicolas Cavallari 
Acked-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtl8192cu: Add new device IDs

2012-03-12T19:31:36+00:00

commit 6cddafab54e9a17b2efefe982547865955a5ff3a upstream.

The latest vendor (non-mac80211) driver of 9/22/2011 shows some new
device IDs for rtl8192cu. In addition, some typos in the table are
fixed and one duplicate is removed.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix key removal

2012-03-12T19:31:26+00:00

commit 5dcbf480473f6c3f06ad2426b7517038a2a18911 upstream.

When trying to remove a key, we always send key
flags just setting the key type, not including
the multicast flag and the key ID. As a result,
whenever any key was removed, the unicast key 0
would be removed, causing a complete connection
loss after the second rekey (the first doesn't
cause a key removal). Fix the key removal code
to include the key ID and multicast flag, thus
removing the correct key.

Reported-by: Alexander Schnaidt 
Tested-by: Alexander Schnaidt 
Signed-off-by: Johannes Berg 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: prevent writes to const data on AR9160

2012-03-12T19:31:26+00:00

commit 9bbb8168ed3d8b946f9c1901a63a675012de88f2 upstream.

Duplicate the data for iniAddac early on, to avoid having to do redundant
memcpy calls later. While we're at it, make AR5416 < v2.2 use the same
codepath. Fixes a reported crash on x86.

Signed-off-by: Felix Fietkau 
Reported-by: Magnus Määttä 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: stop on rates with idx -1 in ath9k rate control's .tx_status

2012-03-01T00:31:15+00:00

commit 2504a6423b9ab4c36df78227055995644de19edb upstream.

Rate control algorithms are supposed to stop processing when they
encounter a rate with the index -1.  Checking for rate->count not being
zero is not enough.

Allowing a rate with negative index leads to memory corruption in
ath_debug_stat_rc().

One consequence of the bug is discussed at
https://bugzilla.redhat.com/show_bug.cgi?id=768639

Signed-off-by: Pavel Roskin 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: fix a RTS/CTS timeout regression

2012-02-20T20:46:15+00:00

commit 55a2bb4a6d5e8c7b324d003e130fd9aaf33be4e6 upstream.

commit adb5066 "ath9k_hw: do not apply the 2.4 ghz ack timeout
workaround to cts" reduced the hardware CTS timeout to the normal
values specified by the standard, but it turns out while it doesn't
need the same extra time that it needs for the ACK timeout, it
does need more than the value specified in the standard, but only
for 2.4 GHz.

This patch brings the CTS timeout value in sync with the initialization
values, while still allowing adjustment for bigger distances.

Signed-off-by: Felix Fietkau 
Reported-by: Seth Forshee 
Reported-by: Marek Lindner 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix a WEP crypto related regression

2012-02-20T20:46:14+00:00

commit f88373fa47f3ce6590fdfaa742d0ddacc2ae017f upstream.

commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag"
fixed the interpretation of the KeyMiss flag for keycache based lookups,
however WEP encryption uses a static index, so KeyMiss is always asserted
for it, even though frames are decrypted properly.
Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based
lookup was performed.

Signed-off-by: Felix Fietkau 
Reported-by: Laurent Bonnans 
Reported-by: Jurica Vukadin 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: Fix kernel panic during driver initilization

2012-02-20T20:46:14+00:00

commit 07445f688218a48bde72316aed9de4fdcc173131 upstream.

all works need to be initialized before ieee80211_register_hw
to prevent mac80211 call backs such as drv_start, drv_config
getting started. otherwise we would queue/cancel works before
initializing them and it leads to kernel panic.
this issue can be recreated with the following script
in Chrome laptops with AR928X cards, with background scan
running (or) Network manager is running

while true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
done

	 EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
	 ---[ end trace 4f86d6139a9900ef ]---
	 Registered led device: ath9k-phy0
	 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
	 irq=16
	 Kernel panic - not syncing: Fatal exception
	 Pid: 456, comm: wpa_supplicant Tainted: G      D
	 3.0.13 #1
	Call Trace:
	 [<81379e21>] panic+0x53/0x14a
	 [<81004a30>] oops_end+0x73/0x81
	 [<81004b53>] die+0x4c/0x55
	 [<81002710>] do_trap+0x7c/0x83
	 [<81002855>] ? do_bounds+0x58/0x58
	 [<810028cc>] do_invalid_op+0x77/0x81
	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
	 [<810489ec>] ? sched_clock_cpu+0x81/0x11f
	 [<8103f809>] ? wait_on_work+0xe2/0xf7
	 [<8137f807>] error_code+0x67/0x6c
	 [<810300d8>] ? wait_consider_task+0x4ba/0x84c
	 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1
	 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67
	 [<81040a91>] cancel_work_sync+0xf/0x11
	 [] ath_set_channel+0x62/0x25c [ath9k]
	 [] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
	 [] ath_radio_disable+0x3f1/0x68e [ath9k]
	 [] ieee80211_hw_config+0x111/0x116 [mac80211]
	 [] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
	 [] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
	 [<812dbed8>] __dev_open+0x82/0xab

Cc: Gary Morain 
Cc: Paul Stewart 
Cc: Vasanthakumar Thiagarajan 
Tested-by: Mohammed Shafi Shajakhan 
Signed-off-by: Rajkumar Manoharan 
Signed-off-by: Mohammed Shafi Shajakhan 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman