linux.git/drivers/net/wireless, branch v3.9-rc5

rtlwifi: usb: add missing freeing of skbuff

2013-03-18T19:20:38+00:00

Signed-off-by: Jussi Kivilinna 
Acked-by: Larry Finger 
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville

mwifiex: cancel cmd timer and free curr_cmd in shutdown process

2013-03-18T19:20:38+00:00

curr_cmd points to the command that is in processing or waiting
for its command response from firmware. If the function shutdown
happens to occur at this time we should cancel the cmd timer and
put the command back to free queue.

Cc:  # 3.8
Tested-by: Marco Cesarano 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville

mwifiex: skip pending commands after function shutdown

2013-03-18T19:20:38+00:00

During rmmod mwifiex_sdio processing FUNC_SHUTDOWN command is
sent to firmware. Firmware expcets only FUNC_INIT once WLAN
function is shut down.

Any command pending in the command queue should be ignored and
freed.

Cc:  # 3.8
Tested-by: Daniel Drake 
Tested-by: Marco Cesarano 
Signed-off-by: Bing Zhao 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: John W. Linville

mwifiex: fix race when queuing commands

2013-03-18T19:20:36+00:00

Running the following script repeatedly on XO-4 with SD8787
produces command timeout and system lockup.

insmod mwifiex_sdio.ko
sleep 1
ifconfig eth0 up
iwlist eth0 scan &
sleep 0.5
rmmod mwifiex_sdio

mwifiex_send_cmd_async() is called for sync as well as async
commands. (mwifiex_send_cmd_sync() internally calls it for
sync command.)

"adapter->cmd_queued" gets filled inside mwifiex_send_cmd_async()
routine for both types of commands. But it is used only for sync
commands in mwifiex_wait_queue_complete(). This could lead to a
race when two threads try to queue a sync command with another
sync/async command simultaneously.

Get rid of global variable and pass command node as a parameter
to mwifiex_wait_queue_complete() to fix the problem.

Cc:  # 3.8
Reported-by: Daniel Drake 
Tested-by: Daniel Drake 
Tested-by: Marco Cesarano 
Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville

ath9k: limit tx path hang check to normal data queues

2013-03-18T19:20:35+00:00

The beacon and multicast-buffer queues are managed by the beacon
tasklet, and the generic tx path hang check does not help in any way
here. Running it on those queues anyway can introduce some race
conditions leading to unnecessary chip resets.

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville

ath9k_hw: revert chainmask to user configuration after calibration

2013-03-18T19:20:34+00:00

The commit 'ath9k_hw: fix calibration issues on chainmask that don't
include chain 0' changed the hardware chainmask to the chip chainmask
for the duration of the calibration, but the revert to user
configuration in the reset path runs too early.

That causes some issues with limiting the number of antennas (including
spurious failure in hardware-generated packets).

Fix this by reverting the chainmask after the essential parts of the
calibration that need the workaround, and before NF calibration is run.

Signed-off-by: Felix Fietkau 
Reported-by: Wojciech Dubowik 
Tested-by: Wojciech Dubowik 
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville

iwl3945: fix length of dma buffers

2013-03-18T19:20:34+00:00

commit bdb084b22d8aee66c87af5e9c36bd6cf7f3bccfd
Author: Stanislaw Gruszka 
Date:   Wed Feb 13 15:49:08 2013 +0100

    iwlegacy: more checks for dma mapping errors

broke il3945_tx_skb() dma buffer length settings, what results on
firmware errors like showed below and make 3945 device non usable.

iwl3945 0000:02:00.0: Microcode SW error detected. Restarting 0x82000008.
iwl3945 0000:02:00.0: Loaded firmware version: 15.32.2.9
iwl3945 0000:02:00.0: Start IWL Error Log Dump:
iwl3945 0000:02:00.0: Status: 0x000202E4, count: 1
iwl3945 0000:02:00.0: Desc 	Time	   asrtPC blink2 ilink1  nmiPC   Line
iwl3945 0000:02:00.0: SYSASSERT     (0x5) 0000208934 0x008B6 0x0035E 0x00320 0x00000 267
iwl3945 0000:02:00.0: Error Reply type 0x00000001 cmd

Reported-by: Zdenek Kabelac 
Reported-by: Krzysztof Kolasa 
Reported-by: Pedro Francisco 
Signed-off-by: Stanislaw Gruszka 
Signed-off-by: John W. Linville

rtlwifi: rtl8192cu: Fix problem that prevents reassociation

2013-03-13T18:18:53+00:00

The driver was failing to clear the BSSID when a disconnect happened. That
prevented a reconnection. This problem is reported at
https://bugzilla.redhat.com/show_bug.cgi?id=789605,
https://bugzilla.redhat.com/show_bug.cgi?id=866786,
https://bugzilla.redhat.com/show_bug.cgi?id=906734, and
https://bugzilla.kernel.org/show_bug.cgi?id=46171.

Thanks to Jussi Kivilinna for making the critical observation
that led to the solution.

Reported-by: Jussi Kivilinna 
Tested-by: Jussi Kivilinna 
Tested-by: Alessandro Lannocca 
Signed-off-by: Larry Finger 
Cc: Stable 
Signed-off-by: John W. Linville

rt2x00: fix rt2x00 to work with the new ralink SoC config symbols

2013-03-13T18:18:53+00:00

Since v3.9-rc1 the kernel has basic support for Ralink WiSoC. The config symbols
are named slightly different than before. Fix the rt2x00 to match the new
symbols.

The commit causing this breakage is:
commit ae2b5bb6570481b50a7175c64176b82da0a81836
Author: John Crispin 
Date:   Sun Jan 20 22:05:30 2013 +0100
MIPS: ralink: adds Kbuild files

Signed-off-by: John Crispin 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville

rtlwifi: rtl8192cu: Fix schedule while atomic bug splat

2013-03-08T20:58:07+00:00

When run at debug 3 or higher, rtl8192cu reports a BUG as follows:

BUG: scheduling while atomic: kworker/u:0/5281/0x00000002
INFO: lockdep is turned off.
Modules linked in: rtl8192cu rtl8192c_common rtlwifi fuse af_packet bnep bluetooth b43 mac80211 cfg80211 ipv6 snd_hda_codec_conexant kvm_amd k
vm snd_hda_intel snd_hda_codec bcma rng_core snd_pcm ssb mmc_core snd_seq snd_timer snd_seq_device snd i2c_nforce2 sr_mod pcmcia forcedeth i2c_core soundcore
 cdrom sg serio_raw k8temp hwmon joydev ac battery pcmcia_core snd_page_alloc video button wmi autofs4 ext4 mbcache jbd2 crc16 thermal processor scsi_dh_alua
 scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_acpi pata_amd [last unloaded: rtlwifi]
Pid: 5281, comm: kworker/u:0 Tainted: G        W    3.8.0-wl+ #119
Call Trace:
 [] __schedule_bug+0x62/0x70
 [] __schedule+0x730/0xa30
 [] ? usb_hcd_link_urb_to_ep+0x19/0xa0
 [] schedule+0x24/0x70
 [] schedule_timeout+0x18c/0x2f0
 [] ? wait_for_common+0x40/0x180
 [] ? ehci_urb_enqueue+0xf1/0xee0
 [] ? trace_hardirqs_on+0xd/0x10
 [] wait_for_common+0xe5/0x180
 [] ? try_to_wake_up+0x2d0/0x2d0
 [] wait_for_completion_timeout+0xe/0x10
 [] usb_start_wait_urb+0x8c/0x100
 [] usb_control_msg+0xd9/0x130
 [] _usb_read_sync+0xcd/0x140 [rtlwifi]
 [] _usb_read32_sync+0xe/0x10 [rtlwifi]
 [] rtl92cu_update_hal_rate_table+0x1a5/0x1f0 [rtl8192cu]

The cause is a synchronous read from routine rtl92cu_update_hal_rate_table().
The resulting output is not critical, thus the debug statement is
deleted.

Reported-by: Jussi Kivilinna 
Signed-off-by: Larry Finger 
Cc: Stable 
Signed-off-by: John W. Linville