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

rt2800usb: Don't perform DMA from stack

2014-07-07T19:04:34+00:00

Function rt2800usb_autorun_detect() passes the address of a variable
allocated onto the stack to be used for DMA by the USB layer. This has
been caught by my debugging-enabled kernel.

This patch change things in order to allocate that variable via
kmalloc, and it adjusts things to handle the kmalloc failure case,
propagating the error.

[ 7363.238852] ------------[ cut here ]------------
[ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0()
[ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4]
[ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib]
[ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G           O  3.16.0-rc3-wl+ #31
[ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009
[ 7363.297511]  0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758
[ 7363.305062]  ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0
[ 7363.312622]  ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8
[ 7363.320161] Call Trace:
[ 7363.322661]  [] dump_stack+0x4d/0x6f
[ 7363.327847]  [] warn_slowpath_common+0x82/0xb0
[ 7363.333893]  [] warn_slowpath_fmt+0x47/0x50
[ 7363.339686]  [] check_for_stack+0xa4/0xf0
[ 7363.345298]  [] debug_dma_map_page+0x10c/0x150
[ 7363.351367]  [] usb_hcd_map_urb_for_dma+0x229/0x720
[ 7363.357890]  [] usb_hcd_submit_urb+0x2fd/0x930
[ 7363.363929]  [] ? irq_work_queue+0x71/0xd0
[ 7363.369617]  [] ? wake_up_klogd+0x37/0x50
[ 7363.375219]  [] ? console_unlock+0x1e5/0x420
[ 7363.381081]  [] ? vprintk_emit+0x245/0x530
[ 7363.386773]  [] usb_submit_urb+0x30c/0x580
[ 7363.392462]  [] usb_start_wait_urb+0x65/0xf0
[ 7363.398325]  [] usb_control_msg+0xcd/0x110
[ 7363.404014]  [] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb]
[ 7363.411544]  [] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb]
[ 7363.418986]  [] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb]
[ 7363.426168]  [] rt2800_probe_hw+0x11d/0xf90 [rt2800lib]
[ 7363.432989]  [] rt2800usb_probe_hw+0xd/0x50 [rt2800usb]
[ 7363.439808]  [] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib]
[ 7363.446992]  [] ? ieee80211_led_names+0xb8/0x100 [mac80211]
[ 7363.454156]  [] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb]
[ 7363.460971]  [] rt2800usb_probe+0x10/0x20 [rt2800usb]
[ 7363.467616]  [] usb_probe_interface+0xce/0x1c0
[ 7363.473651]  [] really_probe+0x70/0x240
[ 7363.479079]  [] __driver_attach+0xa1/0xb0
[ 7363.484682]  [] ? __device_attach+0x70/0x70
[ 7363.490461]  [] bus_for_each_dev+0x63/0xa0
[ 7363.496146]  [] driver_attach+0x19/0x20
[ 7363.501570]  [] bus_add_driver+0x178/0x220
[ 7363.507270]  [] driver_register+0x5b/0xe0
[ 7363.512874]  [] usb_register_driver+0xa0/0x170
[ 7363.518905]  [] ? 0xffffffffa0079fff
[ 7363.524074]  [] rt2800usb_driver_init+0x1e/0x20 [rt2800usb]
[ 7363.531247]  [] do_one_initcall+0x84/0x1b0
[ 7363.536932]  [] ? kfree+0xd0/0x110
[ 7363.541931]  [] ? __vunmap+0xaa/0xf0
[ 7363.547538]  [] load_module+0x1aee/0x2040
[ 7363.553141]  [] ? store_uevent+0x50/0x50
[ 7363.558676]  [] SyS_init_module+0x9e/0xc0
[ 7363.564285]  [] system_call_fastpath+0x16/0x1b
[ 7363.570338] ---[ end trace 01ef5f822bea9882 ]---

Signed-off-by: Andrea Merello 
Acked-by: Helmut Schaa 
Signed-off-by: John W. Linville

rt2x00: fix rfkill regression on rt2500pci

2014-06-17T18:11:16+00:00

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.")
Cc: stable@vger.kernel.org
Bisected-by: Niels 
Reported-and-tested-by: Niels 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

rt2800usb:fix hang during firmware load

2014-06-17T18:11:16+00:00

The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) boots into a state that does
not actually require loading a firmware file. The vendors driver finds out
about this by checking a firmware state register, so this patch adds this here.

Finally, with this patch applied, my wifi dongle actually becomes
useful (scan + connect to wpa network works).

Signed-off-by: Michael Braun 
Acked-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

rt2800usb:fix efuse detection

2014-06-17T18:11:15+00:00

The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) currently does not
load. One thing observed is that the vendors driver detects EFUSE mode
for this device, but rt2800usb does not. This is due to rt2800usb
lacking a check for the firmware mode present in the vendors driver,
that this patch adopts for rt2800usb.

With this patch applied, the 'RF chipset' detection does no longer fail.

Signed-off-by: Michael Braun 
Acked-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

rt2x00: disable TKIP on USB

2014-06-16T15:23:33+00:00

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]

Cc: stable@vger.kernel.org
Reported-and-tested-by: Peter Wu 
Reported-and-tested-by: Pontus Fuchs 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

rt2x00: Endless loop on hub port power down

2014-05-22T18:04:36+00:00

I've met an endless (or at least very long) loop if I power down the usb
port on witch a usb wifi key is plugged.
(Ok, it's not very smart to power down a usb port when a usb key is in
used... but still, I think that should not lead to an endless loop).

I have a lot of:
ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71

(-71==-EPROTO)

How to reproduce:
- plug an usb wifi key
- ip link set wlan0 up
- hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0

hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c

The following patch prevents the endless loop, but I'm really not sure
that The Right Way To Do It (R)

Signed-off-by: Richard Genoud 
Signed-off-by: John W. Linville

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2014-05-13T19:27:44+00:00

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2014-04-30T16:04:27+00:00

Conflicts:
	net/mac80211/chan.c

rt2x00: restore original beaconing state

2014-04-22T19:06:31+00:00

After changing local per interface beacon setting restore original
global beaconing state.

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

rt2x00: fix beaconing on USB

2014-04-22T18:07:48+00:00

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

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville