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

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

2014-07-09T18:14:01+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: Greg Kroah-Hartman

iwlwifi: pcie: try to get ownership several times

2014-07-09T18:14:01+00:00

commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5 upstream.

Some races with the hardware can happen when we take
ownership of the device. Don't give up after the first try.

Reviewed-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

rt2x00: fix rfkill regression on rt2500pci

2014-07-09T18:14:00+00:00

commit 616a8394b5df8c88f4dd416f4527439a4e365034 upstream.

As reported by Niels, starting rfkill polling during device probe
(commit e2bc7c5, generally sane change) broke rfkill on rt2500pci
device. I considered that bug as some initalization issue, which
should be fixed on rt2500pci specific code. But after several
attempts (see bug report for details) we fail to find working solution.
Hence I decided to revert to old behaviour on rt2500pci to fix
regression.

Additionally patch also unregister rfkill on device remove instead
of ifconfig down, what was another issue introduced by bad commit.

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=73821

Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.")
Bisected-by: Niels 
Reported-and-tested-by: Niels 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: disable TKIP on USB

2014-07-09T18:14:00+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: Greg Kroah-Hartman

ath9k: protect tid->sched check

2014-06-07T20:25:40+00:00

[ Upstream commit 21f8aaee0c62708654988ce092838aa7df4d25d8 ]

We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That
is race condition which can result of doing list_del(&tid->list) twice
(second time with poisoned list node) and cause crash like shown below:

[424271.637220] BUG: unable to handle kernel paging request at 00100104
[424271.637328] IP: [] ath_tx_aggr_sleep+0x62/0xe0 [ath9k]
...
[424271.639953] Call Trace:
[424271.639998]  [] ? ath9k_get_survey+0x110/0x110 [ath9k]
[424271.640083]  [] ath9k_sta_notify+0x42/0x50 [ath9k]
[424271.640177]  [] sta_ps_start+0x8f/0x1c0 [mac80211]
[424271.640258]  [] ? free_compound_page+0x2e/0x40
[424271.640346]  [] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211]
[424271.640437]  [] ? kmem_cache_free+0x1d8/0x1f0
[424271.640510]  [] ? kfree_skbmem+0x34/0x90
[424271.640578]  [] ? put_page+0x2c/0x40
[424271.640640]  [] ? kfree_skbmem+0x34/0x90
[424271.640706]  [] ? kfree_skbmem+0x34/0x90
[424271.640787]  [] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211]
[424271.640897]  [] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211]
[424271.641009]  [] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211]
[424271.641104]  [] ? ip_output+0x7e/0xd0
[424271.641182]  [] ieee80211_rx+0x307/0x7c0 [mac80211]
[424271.641266]  [] ath_rx_tasklet+0x88e/0xf70 [ath9k]
[424271.641358]  [] ? ieee80211_rx+0x1dc/0x7c0 [mac80211]
[424271.641445]  [] ath9k_tasklet+0xcb/0x130 [ath9k]

Bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=70551

Reported-and-tested-by: Max Sydorenko 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville 
[ xl: backported to 3.10: adjusted context ]
Signed-off-by: Xiangyu Lu 
Signed-off-by: Greg Kroah-Hartman

brcmsmac: fix deadlock on missing firmware

2014-06-07T20:25:34+00:00

commit 8fc1e8c240aab968db658b2d8d079b4391207a36 upstream.

When brcm80211 firmware is not installed networking hangs.
A deadlock happens because we call ieee80211_unregister_hw()
from the .start callback of struct ieee80211_ops. When .start
is called we are under rtnl lock and ieee80211_unregister_hw()
tries to take it again.

Function call stack:

dev_change_flags()
	__dev_change_flags()
		__dev_open()
			ASSERT_RTNL() <-- Assert rtnl lock
			ops->ndo_open()

.ndo_open = ieee80211_open,

ieee80211_open()
	ieee80211_do_open()
		drv_start()
			local->ops->start()

.start = brcms_ops_start,

brcms_ops_start()
	brcms_remove()
		ieee80211_unregister_hw()
			rtnl_lock() <-- Here we deadlock

Introduced by:
commit 25b5632fb35ca61b8ae3eee235edcdc2883f7a5e
("brcmsmac: request firmware in .start() callback")

This patch fixes the bug by removing the call to brcms_remove()
and moves the brcms_request_fw() call to the top of the .start
callback to not initiate anything unless firmware is installed.

Signed-off-by: Emil Goode 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

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

2014-06-07T20:25:34+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 
Signed-off-by: Greg Kroah-Hartman

rt2x00: fix beaconing on USB

2014-06-07T20:25:33+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: Greg Kroah-Hartman

rtlwifi: rtl8188ee: initialize packet_beacon

2014-05-13T11:59:45+00:00

commit 328e203fc35f0b4f6df1c4943f74cf553bcc04f8 upstream.

static code analysis from cppcheck reports:

[drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]:
  (error) Uninitialized variable: packet_beacon

packet_beacon is not initialized and hence packet_beacon
contains garbage from the stack, so set it to false.

Signed-off-by: Colin Ian King 
Acked-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192se: Fix regression due to commit 1bf4bbb

2014-05-13T11:59:44+00:00

commit 5f9186990ec4579ee5b7a99b3254c29eda479f36 upstream.

Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:

Commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac
Author: Felix Fietkau 
Title: mac80211: send control port protocol frames to the VO queue

There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.

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

Reported-by: Alex Miller 
Tested-by: Alex Miller 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman