linux-stable.git/drivers/net/wireless, branch v3.2.24

iwlegacy: don't mess up the SCD when removing a key

2012-07-25T03:11:23+00:00

commit b48d96652626b315229b1b82c6270eead6a77a6d upstream.

When we remove a key, we put a key index which was supposed
to tell the fw that we are actually removing the key. But
instead the fw took that index as a valid index and messed
up the SRAM of the device.

This memory corruption on the device mangled the data of
the SCD. The impact on the user is that SCD queue 2 got
stuck after having removed keys.

Reported-by: Paul Bolle 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust filename, context and variable name]
Signed-off-by: Ben Hutchings

iwlegacy: always monitor for stuck queues

2012-07-25T03:11:22+00:00

commit c2ca7d92ed4bbd779516beb6eb226e19f7f7ab0f upstream.

This is iwlegacy version of:

commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912
Author: Johannes Berg 
Date:   Sun Mar 4 08:50:46 2012 -0800

    iwlwifi: always monitor for stuck queues

    If we only monitor while associated, the following
    can happen:
     - we're associated, and the queue stuck check
       runs, setting the queue "touch" time to X
     - we disassociate, stopping the monitoring,
       which leaves the time set to X
     - almost 2s later, we associate, and enqueue
       a frame
     - before the frame is transmitted, we monitor
       for stuck queues, and find the time set to
       X, although it is now later than X + 2000ms,
       so we decide that the queue is stuck and
       erroneously restart the device

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust filename, function and variable names]
Signed-off-by: Ben Hutchings

rt2x00usb: fix indexes ordering on RX queue kick

2012-07-25T03:11:22+00:00

commit efd821182cec8c92babef6e00a95066d3252fda4 upstream.

On rt2x00_dmastart() we increase index specified by Q_INDEX and on
rt2x00_dmadone() we increase index specified by Q_INDEX_DONE. So entries
between Q_INDEX_DONE and Q_INDEX are those we currently process in the
hardware. Entries between Q_INDEX and Q_INDEX_DONE are those we can
submit to the hardware.

According to that fix rt2x00usb_kick_queue(), as we need to submit RX
entries that are not processed by the hardware. It worked before only
for empty queue, otherwise was broken.

Note that for TX queues indexes ordering are ok. We need to kick entries
that have filled skb, but was not submitted to the hardware, i.e.
started from Q_INDEX_DONE and have ENTRY_DATA_PENDING bit set.

From practical standpoint this fixes RX queue stall, usually reproducible
in AP mode, like for example reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=828824

Reported-and-tested-by: Franco Miceli 
Reported-and-tested-by: Tom Horsley 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

brcmsmac: "INTERMEDIATE but not AMPDU" only when tracing

2012-07-25T03:10:59+00:00

commit 6ead629b27269c553c9092c47cd8f5ab0309ee3b upstream.

I keep getting the following messages on the log buffer:
[ 2167.097507] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2281.331305] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2281.332539] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2329.876605] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2329.877354] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2462.280756] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU
[ 2615.651689] ieee80211 phy0: brcms_c_dotxstatus: INTERMEDIATE but not AMPDU

From the code comment I understand that this something that can -
and does, quite frequently - happen.

Signed-off-by: Eldad Zack 
Acked-by: Franky Lin
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

net/wireless: ipw2x00: add supported cipher suites to wiphy initialization

2012-07-25T03:10:57+00:00

commit a141e6a0097118bb35024485f1faffc0d9042f5c upstream.

Driver doesn't report its supported cipher suites through cfg80211
interface. It still uses wext interface and probably will not work
through nl80211, but will at least correctly advertise supported
features.

Bug was reported by Omar Siam.
https://bugzilla.kernel.org/show_bug.cgi?id=43049

Signed-off-by: Stanislav Yakovlev 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rtl8187: ->brightness_set can not sleep

2012-07-25T03:10:56+00:00

commit 0fde0a8cfd0ede7f310d6a681c8e5a7cb3e32406 upstream.

Fix:

BUG: sleeping function called from invalid context at kernel/workqueue.c:2547
in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant
2 locks held by wpa_supplicant/629:
 #0:  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x14/0x20
 #1:  (&trigger->leddev_list_lock){.+.?..}, at: [] led_trigger_event+0x21/0x80
Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686
Call Trace:
 [] __might_sleep+0x126/0x1d0
 [] wait_on_work+0x2c/0x1d0
 [] __cancel_work_timer+0x6a/0x120
 [] cancel_delayed_work_sync+0x10/0x20
 [] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187]
 [] led_trigger_event+0x5c/0x80
 [] ieee80211_led_radio+0x1d/0x40 [mac80211]
 [] ieee80211_stop_device+0x13/0x230 [mac80211]

Removing _sync is ok, because if led_on work is currently running
it will be finished before led_off work start to perform, since
they are always queued on the same mac80211 local->workqueue.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176

Signed-off-by: Stanislaw Gruszka 
Acked-by: Larry Finger 
Acked-by: Hin-Tak Leung 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

mwifiex: fix wrong return values in add_virtual_intf() error cases

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

commit 858faa57dd9e2b91f3f870fbb1185982e42f5a2b upstream

backported for linux-3.2.y, linux-3.3.y, linux-3.4.y

add_virtual_intf() needs to return an ERR_PTR(), instead of NULL,
on errors, otherwise cfg80211 will crash.

Reported-by: Johannes Berg 
Signed-off-by: Bing Zhao 
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

rtlwifi: rtl8192cu: New USB IDs

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

commit f63d7dabd5da9ef41f28f6d69b29bc084db0ca5a upstream.

The latest Realtek driver for the RTL8188CU and RTL8192CU chips adds three
new USB IDs.

Reported-by: Xose Vazquez Perez 
Signed-off-by: Larry Finger 
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