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

rtlwifi: Convert to asynchronous firmware load

2012-04-02T17:32:10+00:00

commit b0302aba812bcc39291cdab9ad7e37008f352a91 upstream.

This patch addresses a kernel bugzilla report and two recent mail threads.

The kernel bugzilla report is https://bugzilla.kernel.org/show_bug.cgi?id=42632,
which reports a udev timeout on boot.

The first mail thread, which was on LKML (http://lkml.indiana.edu/hypermail/
linux/kernel/1112.3/00965.html) was for a WARNING that occurs after a
suspend/resume cycle for rtl8192cu.

The scond mail thread (http://marc.info/?l=linux-wireless&m=132655490826766&w=2)
concerned changes in udev that break drivers that delay while firmware is loaded
on modprobe.

This patch converts all rtlwifi-based drivers to use the asynchronous firmware
loading mechanism. Drivers rtl8192ce, rtl8192cu and rtl8192de share a common
callback routine. Driver rtl8192se needs different handling of the firmware,
thus it has its own code.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

p54spi: Release GPIO lines and IRQ on error in p54spi_probe

2012-04-02T17:31:53+00:00

commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream.

This makes it possible to reload driver if insmod has failed due to
missing firmware.

Signed-off-by: Max Filippov 
Acked-by: Christian Lamparter 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k: fix going to full-sleep on PS idle

2012-04-02T17:31:52+00:00

commit c1afdaff90538ef085b756454f12b29575411214 upstream.

The check for PS_WAIT_FOR_TX_ACK was inverted, the hardware should only go
to full sleep if no tx is pending.

Reported-by: Sujith Manoharan 
Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: always monitor for stuck queues

2012-04-02T17:31:52+00:00

commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream.

If we only monitor while associated, the following
can happen:
 - we're associated, and the queue stuck check
   runs, setting the queue "touch" time to X
 - we disassociate, stopping the monitoring,
   which leaves the time set to X
 - almost 2s later, we associate, and enqueue
   a frame
 - before the frame is transmitted, we monitor
   for stuck queues, and find the time set to
   X, although it is now later than X + 2000ms,
   so we decide that the queue is stuck and
   erroneously restart the device

It happens more with P2P because there we can
go between associated/unassociated frequently.

Reported-by: Ben Cahill 
Signed-off-by: Johannes Berg 
Signed-off-by: Wey-Yi Guy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192ce: Fix loss of receive performance

2012-04-02T17:31:52+00:00

commit a9b89e2567c743483e6354f64d7a7e3a8c101e9e upstream.

Driver rtl8192ce when used with the RTL8188CE device would start at about
20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the
symptoms is that the AP would need to retransmit each packet 4 of 5 times
before the driver would acknowledge it. Recovery is possible only by
unloading and reloading the driver. This problem was reported at
https://bugzilla.redhat.com/show_bug.cgi?id=770207.

The problem is due to a missing update of the gain setting.

Signed-off-by: Jingjun Wu 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu

2012-04-02T17:31:51+00:00

commit ebecdcc12fed5d3c81853dea61a0a78a5aefab52 upstream.

When driver rtl8192cu is used with the debug level set to 3 or greater,
the result is "sleeping function called from invalid context" due to
an rcu_read_lock() call in the DM refresh routine in driver rtl8192c.
This lock is not necessary as the USB driver does not use the struct
being protected, thus the lock is set only when a PCI interface is
active.

This bug is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42775.

Reported-by: Ronald Wahl 
Tested-by: Ronald Wahl 
Signed-off-by: Larry Finger 
Cc: Ronald Wahl 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: Handle previous allocation failures when freeing device memory

2012-04-02T17:31:48+00:00

commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream.

Handle previous allocation failures when freeing device memory

Signed-off-by: Simon Graham 
Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtlwifi: rtl8192c_common: rtl8192de: Check for allocation failures

2012-04-02T17:31:42+00:00

commit 76a92be537f1c8c259e393632301446257ca3ea9 upstream.

In https://bugzilla.redhat.com/show_bug.cgi?id=771656, a kernel bug was
triggered due to a failed skb allocation that was not checked. This event
lead to an audit of all memory allocations in the complete rtlwifi family
of drivers. This patch fixes the rest.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: Add support for D-Link DWA-127 to rt2800usb.

2012-04-02T17:31:36+00:00

commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream.

This is an RT3070 based device.

Reported-by: Mikhail Kryshen 
Signed-off-by: Gertjan van Wingerde 
Acked-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: fix random stalls

2012-03-12T18:00:17+00:00

Is possible that we stop queue and then do not wake up it again,
especially when packets are transmitted fast. That can be easily
reproduced with modified tx queue entry_num to some small value e.g. 16.

If mac80211 already hold local->queue_stop_reason_lock, then we can wait
on that lock in both rt2x00queue_pause_queue() and
rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
is possible that __ieee80211_wake_queue() will be performed before
__ieee80211_stop_queue(), hence we stop queue and newer wake up it
again.

Another race condition is possible when between rt2x00queue_threshold()
check and rt2x00queue_pause_queue() we will process all pending tx
buffers on different cpu. This might happen if for example interrupt
will be triggered on cpu performing rt2x00mac_tx().

To prevent race conditions serialize pause/unpause by queue->tx_lock.

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