kernel/linux.git/drivers/net/wireless, branch v3.0.35

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

2012-06-17T18:23:12+00:00

commit d6ee27eb13beab94056e0de52d81220058ca2297 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. The message is the log that was printed is: Queue 2 stuck for 10000ms This doesn't seem to fix the higher queues that get stuck from time to time. Reviewed-by: Meenakshi Venkataraman Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wl1251: fix oops on early interrupt

2012-06-09T15:33:05+00:00

commit f380f2c4a12e913356bd49f8790ec1063c4fe9f8 upstream. This driver disables interrupt just after requesting it and enables it later, after interface is up. However currently there is a time window between request_irq() and disable_irq() where if interrupt arrives, the driver oopses because it's not yet ready to process it. This can be reproduced by inserting the module, associating and removing the module multiple times. Eliminate this race by setting IRQF_NOAUTOEN flag before request_irq(). Signed-off-by: Grazvydas Ignotas Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwlwifi: update BT traffic load states correctly

2012-06-09T15:32:58+00:00

commit 882dde8eb0d49ce0f853f8f4084dde56a21fe55f upstream. When BT traffic load changes from its previous state, a new LQ command needs to be sent down to the firmware. This needs to be done only once per change. The state variable that keeps track of this change is last_bt_traffic_load. However, it was not being updated when the change had been handled. Not updating this variable was causing a flood of advanced BT config commands to be sent to the firmware. Fix this. Signed-off-by: Meenakshi Venkataraman Signed-off-by: Wey-Yi Guy Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wl1251: fix crash on remove due to leftover work item

2012-05-07T15:56:50+00:00

commit 4c1bcdb5a3354b250b82a67549f57ac27a3bb85f upstream. This driver currently leaves elp_work behind when stopping, which occasionally results in data corruption because work function ends up accessing freed memory, typical symptoms of this are various worker_thread crashes. Fix it by cancelling elp_work. Signed-off-by: Grazvydas Ignotas Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

wl1251: fix crash on remove due to premature kfree

2012-05-07T15:56:49+00:00

commit 328c32f0f85467af5a6c4c3289e168d9ad2555af upstream. Currently SDIO glue frees it's own structure before calling wl1251_free_hw(), which in turn calls ieee80211_unregister_hw(). The later call may result in a need to communicate with the chip to stop it (as it happens now if the interface is still up before rmmod), which means calls are made back to the glue, resulting in freed memory access. Fix this by freeing glue data last. Signed-off-by: Grazvydas Ignotas Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rtlwifi: Fix oops on unload

2012-05-07T15:56:48+00:00

commit 44eb65cfd8da4b9c231238998729e858e963a980 upstream. Under some circumstances, a PCI-based driver reports the following OOPs: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Oops: 0000 [#1] SMP --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Pid: 19627, comm: rmmod Not tainted 3.2.9-2.fc16.x86_64 #1 LENOVO 05962RU/05962RU Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP: 0010:[] [] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Process rmmod (pid: 19627, threadinfo ffff880050262000, task ffff8801156d5cc0) Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Stack: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000002 ffff8801176c2540 ffff880050263ca8 ffffffffa03348e7 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] 0000000000000282 0000000180150014 ffff880050263fd8 ffff8801176c2810 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] ffff880050263bc8 ffffffff810550e2 00000000000002c0 ffff8801176c0d40 Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Call Trace: Mar 19 08:14:35 kvothe kernel: [ 6584.626011] [] _rtl_pci_rx_interrupt+0x187/0x650 [rtlwifi] --snip-- Mar 19 08:14:35 kvothe kernel: [ 6584.626011] Code: ff 09 d0 89 07 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 40 84 f6 89 d3 74 13 84 d2 75 57 <8b> 07 48 83 c4 08 5b 5d c1 e8 1f c3 0f 1f 00 84 d2 74 ed 80 fa Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RIP [] rtl92ce_get_desc+0x19/0xd0 [rtl8192ce] Mar 19 08:14:35 kvothe kernel: [ 6584.626011] RSP Mar 19 08:14:35 kvothe kernel: [ 6584.626011] CR2: 00000000000006e0 Mar 19 08:14:35 kvothe kernel: [ 6584.646491] ---[ end trace 8636c766dcfbe0e6 ]--- This oops is due to interrupts not being disabled in this particular path. Reported-by: Dave Airlie Tested-by: Dave Airlie Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

ipw2200: Fix race condition in the command completion acknowledge

2012-05-07T15:56:40+00:00

commit dd447319895d0c0af423e483d9b63f84f3f8869a upstream. Driver incorrectly validates command completion: instead of waiting for a command to be acknowledged it continues execution. Most of the time driver gets acknowledge of the command completion in a tasklet before it executes the next one. But sometimes it sends the next command before it gets acknowledge for the previous one. In such a case one of the following error messages appear in the log: Failed to send SYSTEM_CONFIG: Already sending a command. Failed to send ASSOCIATE: Already sending a command. Failed to send TX_POWER: Already sending a command. After that you need to reload the driver to get it working again. This bug occurs during roaming (reported by Sam Varshavchik) https://bugzilla.redhat.com/show_bug.cgi?id=738508 and machine booting (reported by Tom Gundersen and Mads Kiilerich) https://bugs.archlinux.org/task/28097 https://bugzilla.redhat.com/show_bug.cgi?id=802106 This patch doesn't fix the delay issue during firmware load. But at least device now works as usual after boot. Signed-off-by: Stanislav Yakovlev Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

rt2x00: Identify rt2800usb chipsets.

2012-04-27T16:51:17+00:00

commit bc93eda7e903ff75cefcb6e247ed9b8e9f8e9783 upstream. According to the latest USB ID database these are all RT2770 / RT2870 / RT307x devices. Signed-off-by: Gertjan van Wingerde Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

rt2800: Add support for the Fujitsu Stylistic Q550

2012-04-27T16:51:17+00:00

commit 3ac44670ad0fca8b6c43b3e4d8494c67c419f494 upstream. Just another USB identifier. Signed-off-by: Alan Cox Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

rt2x00: Add USB device ID of Buffalo WLI-UC-GNHP.

2012-04-27T16:51:17+00:00

commit c18b7806e4f3373b2f296a65fb19251a3b49a532 upstream. This is reported to be an RT3070 based device. Reported-by: Teika Kazura Signed-off-by: Gertjan van Wingerde Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman