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

b43: fix frequency reported on G-PHY with /new/ firmware

2014-07-11T12:33:53+00:00

commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream.

Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).

So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:

commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7
Author: Emmanuel Grumbach 
Date:   Tue Mar 4 16:50:13 2014 +0200

    cfg80211/mac80211: ignore signal if the frame was heard on wrong channel

Reported-by: Aaro Koskinen 
Signed-off-by: Rafał Miłecki 
Tested-by: Aaro Koskinen 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rt2x00: disable TKIP on USB

2014-07-11T12:33:52+00:00

commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream.

On USB we can not get atomically TKIP key. We have to disable support
for TKIP acceleration on USB hardware to avoid bug as showed bellow.

[  860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002

[  860.827280] Call Trace:
[  860.827282]  [] dump_stack+0x4d/0x66
[  860.827284]  [] __schedule_bug+0x47/0x55
[  860.827285]  [] __schedule+0x733/0x7b0
[  860.827287]  [] schedule+0x29/0x70
[  860.827289]  [] schedule_timeout+0x15a/0x2b0
[  860.827291]  [] ? ftrace_raw_event_tick_stop+0xc0/0xc0
[  860.827294]  [] ? __module_text_address+0x12/0x70
[  860.827296]  [] wait_for_completion_timeout+0xb3/0x140
[  860.827298]  [] ? wake_up_state+0x20/0x20
[  860.827301]  [] usb_start_wait_urb+0x7d/0x150
[  860.827303]  [] usb_control_msg+0xc5/0x110
[  860.827305]  [] rt2x00usb_vendor_request+0xc6/0x160  [rt2x00usb]
[  860.827307]  [] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb]
[  860.827309]  [] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb]
[  860.827311]  [] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
[  860.827314]  [] rt2800_get_tkip_seq+0x39/0x50  [rt2800lib]
[  860.827321]  [] ieee80211_get_key+0x218/0x2a0  [mac80211]
[  860.827322]  [] ? __nlmsg_put+0x6c/0x80
[  860.827329]  [] nl80211_get_key+0x22e/0x360 [cfg80211]

Reported-and-tested-by: Peter Wu 
Reported-and-tested-by: Pontus Fuchs 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()

2014-06-09T12:29:05+00:00

commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.

Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Signed-off-by: Ben Hutchings 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]

rtlwifi: rtl8192cu: Fix too long disable of IRQs

2014-06-09T12:29:05+00:00

commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream.

In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
 fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192cu.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

rt2x00: fix beaconing on USB

2014-06-09T12:29:01+00:00

commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream.

When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.

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

rtl8192ce: Fix null dereference in watchdog

2014-05-18T13:58:09+00:00

Dmitry Semyonov reported that after upgrading from 3.2.54 to
3.2.57 the rtl8192ce driver will crash when its interface is brought
up.  The oops message shows:

[ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 1833.611455] IP: [] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce]
...
[ 1833.613326] Call Trace:
[ 1833.613346]  [] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common]
[ 1833.613391]  [] ? process_one_work+0x161/0x269
[ 1833.613425]  [] ? worker_thread+0xc2/0x145
[ 1833.613458]  [] ? manage_workers.isra.25+0x15b/0x15b
[ 1833.613496]  [] ? kthread+0x76/0x7e
[ 1833.613527]  [] ? kernel_thread_helper+0x4/0x10
[ 1833.613563]  [] ? kthread_worker_fn+0x139/0x139
[ 1833.613598]  [] ? gs_change+0x13/0x13

Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta'
parameter was null.  None of the changes to the rtlwifi family between
3.2.54 and 3.2.57 seem to directly cause this, and reverting commit 
f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs')
doesn't fix it.

rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via
rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the
call trace as it was inlined.  That function has been completely
removed upstream which may explain why this crash wasn't seen there.

I'm not sure that it is sensible to completely remove
rtl92c_dm_refresh_rate_adaptive_mask() without making other
compensating changes elsewhere, so try to work around this for 3.2 by
checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask()
and then skipping the call to rtl92ce_update_hal_rate_tbl().

References: https://bugs.debian.org/745137
References: https://bugs.debian.org/745462
Reported-by: Dmitry Semyonov 
Signed-off-by: Ben Hutchings 
Cc: Larry Finger 
Cc: Chaoming Li

b43: Fix machine check error due to improper access of B43_MMIO_PSM_PHY_HDR

2014-04-30T15:23:26+00:00

commit 12cd43c6ed6da7bf7c5afbd74da6959cda6d056b upstream.

Register B43_MMIO_PSM_PHY_HDR is 16 bit one, so accessing it with 32b
functions isn't safe. On my machine it causes delayed (!) CPU exception:

Disabling lock debugging due to kernel taint
mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: b200000000070f0f
mce: [Hardware Error]: TSC 164083803dc
mce: [Hardware Error]: PROCESSOR 2:20fc2 TIME 1396650505 SOCKET 0 APIC 0 microcode 0
mce: [Hardware Error]: Run the above through 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Processor context corrupt
Kernel panic - not syncing: Fatal machine check on current CPU
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

Signed-off-by: Rafał Miłecki 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

ath9k: fix ready time of the multicast buffer queue

2014-04-30T15:23:22+00:00

commit 3b3e0efb5c72c4fc940af50b33626b8a78a907dc upstream.

qi->tqi_readyTime is written directly to registers that expect
microseconds as unit instead of TU.
When setting the CABQ ready time, cur_conf->beacon_interval is in TU, so
convert it to microseconds before passing it to ath9k_hw.

This should hopefully fix some Tx DMA issues with buffered multicast
frames in AP mode.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

iwlwifi: dvm: take mutex when sending SYNC BT config command

2014-04-30T15:23:21+00:00

commit 82e5a649453a3cf23516277abb84273768a1592b upstream.

There is a flow in which we send the host command in SYNC
mode, but we don't take priv->mutex.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1046495

Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
[bwh: Backported to 3.2:
 - Adjust filename, context
 - mutex is priv->shrd->mutex]
Signed-off-by: Ben Hutchings

rtlwifi: rtl8192se: Fix too long disable of IRQs

2014-04-30T15:23:21+00:00

commit 2610decdd0b3808ba20471a999835cfee5275f98 upstream.

In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
 fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192se.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop change to an error path that we don't have]
Signed-off-by: Ben Hutchings