linux-toradex.git/drivers/net/wireless, branch v3.0.29 Linux kernel for Apalis and Colibri modules ath9k: fix max noise floor threshold 2012-04-22T23:21:41+00:00 Rajkumar Manoharan rmanohar@qca.qualcomm.com 2012-03-15T00:38:04+00:00 64bc099c97abc7b2657351629615a8e9f43d6458 commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream. Currently the maximum noise floor limit is set as too high (-60dB). The assumption of having a higher threshold limit is that it would help de-sensitize the receiver (reduce phy errors) from continuous interference. But when we have a bursty interference where there are collisions and then free air time and if the receiver is desensitized too much, it will miss the normal packets too. Lets make use of chips specific min, nom and max limits always. This patch helps to improve the connection stability in congested networks. Cc: Paul Stewart <pstew@google.com> Tested-by: Gary Morain <gmorain@google.com> Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.0/3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2ee0a07028d2cde6e131b73f029dae2b93c50f3a upstream.

Currently the maximum noise floor limit is set as too high (-60dB). The
assumption of having a higher threshold limit is that it would help
de-sensitize the receiver (reduce phy errors) from continuous
interference. But when we have a bursty interference where there are
collisions and then free air time and if the receiver is desensitized too
much, it will miss the normal packets too. Lets make use of chips
specific min, nom and max limits always. This patch helps to improve the
connection stability in congested networks.

Cc: Paul Stewart <pstew@google.com>
Tested-by: Gary Morain <gmorain@google.com>
Signed-off-by: Madhan Jaganathan <madhanj@qca.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
[bwh: Backported to 3.0/3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtlwifi: Add missing DMA buffer unmapping for PCI drivers 2012-04-22T23:21:22+00:00 Larry Finger Larry.Finger@lwfinger.net 2012-03-26T15:48:20+00:00 2586dcec57d8334c5c2f313d840d27148de4e9a3 commit 673f7786e205c87b5d978c62827b9a66d097bebb upstream. In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These are caused by the DMA buffers used for beacons never being unmapped. This bug was also reported at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618 Reported-and-Tested-by: Da Xue <da@lessconfused.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 673f7786e205c87b5d978c62827b9a66d097bebb upstream.

In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver
rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These
are caused by the DMA buffers used for beacons never being unmapped.

This bug was also reported at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618

Reported-and-Tested-by: Da Xue <da@lessconfused.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
p54spi: Release GPIO lines and IRQ on error in p54spi_probe 2012-04-02T16:27:10+00:00 Max Filippov jcmvbkbc@gmail.com 2012-02-29T20:40:08+00:00 2a367a7641e3f3075bfb50cb6ce26d4c66848e3c commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream. This makes it possible to reload driver if insmod has failed due to missing firmware. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream.

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

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtlwifi: rtl8192ce: Fix loss of receive performance 2012-04-02T16:27:09+00:00 Jingjun Wu jingjun_wu@realsil.com.cn 2012-03-03T02:52:14+00:00 75e375312eb27ce49f71ed760e12fe770a32f579 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 <jingjun_wu@realsil.com.cn> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <jingjun_wu@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu 2012-04-02T16:27:09+00:00 Larry Finger Larry.Finger@lwfinger.net 2012-03-02T21:23:36+00:00 debc5a0ed2f7cc40c31ea56f070b1af6920f6c53 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 <ronald.wahl@raritan.com> Tested-by: Ronald Wahl <ronald.wahl@raritan.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ronald Wahl <ronald.wahl@raritan.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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 <ronald.wahl@raritan.com>
Tested-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtlwifi: Handle previous allocation failures when freeing device memory 2012-04-02T16:27:08+00:00 Simon Graham simon.graham@virtualcomputer.com 2012-02-08T00:07:38+00:00 8400bf923e7fd057abc6dc2ab6e00e481b26a793 commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream. Handle previous allocation failures when freeing device memory Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream.

Handle previous allocation failures when freeing device memory

Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2x00: Add support for D-Link DWA-127 to rt2800usb. 2012-04-02T16:27:08+00:00 Gertjan van Wingerde gwingerde@gmail.com 2012-02-11T20:58:09+00:00 dc1c756aeaf15e67a293b4aaedbd062f5026e18e commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream. This is an RT3070 based device. Reported-by: Mikhail Kryshen <mikhail@kryshen.net> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream.

This is an RT3070 based device.

Reported-by: Mikhail Kryshen <mikhail@kryshen.net>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwl3945: fix possible il->txq NULL pointer dereference in delayed works 2012-03-23T18:20:52+00:00 Stanislaw Gruszka sgruszka@redhat.com 2012-03-08T12:16:01+00:00 8290924361675d411266b890ab3b5964dc8e7255 commit 210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream. On il3945_down procedure we free tx queue data and nullify il->txq pointer. After that we drop mutex and then cancel delayed works. There is possibility, that after drooping mutex and before the cancel, some delayed work will start and crash while trying to send commands to the device. For example, here is reported crash in il3945_bg_reg_txpower_periodic(): https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10 Patch fix problem by adding il->txq check on works that send commands, hence utilize tx queue. Reported-by: Clemens Eisserer <linuxhippy@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
commit 210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream.

On il3945_down procedure we free tx queue data and nullify il->txq
pointer. After that we drop mutex and then cancel delayed works. There
is possibility, that after drooping mutex and before the cancel, some
delayed work will start and crash while trying to send commands to
the device. For example, here is reported crash in
il3945_bg_reg_txpower_periodic():
https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10

Patch fix problem by adding il->txq check on works that send commands,
hence utilize tx queue.

Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2x00: fix random stalls 2012-03-19T15:57:44+00:00 Stanislaw Gruszka sgruszka@redhat.com 2012-03-09T11:39:54+00:00 60d3a450571b3d92f5f9f78f2898a7f425031b51 commit 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 upstream. 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. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 upstream.

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.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
carl9170: Fix memory accounting when sta is in power-save mode. 2012-03-12T17:33:01+00:00 Nicolas Cavallari Nicolas.Cavallari@lri.fr 2012-02-23T15:53:34+00:00 2070216144d9c8ff4894a443b093277b42342b12 commit 992d52529d7840236d3059b51c15d5eb9e81a869 upstream. On Access Point mode, when transmitting a packet, if the destination station is in powersave mode, we abort transmitting the packet to the device queue, but we do not reclaim the allocated memory. Given enough packets, we can go in a state where there is no packet on the device queue, but we think the device has no memory left, so no packet gets transmitted, connections breaks and the AP stops working. This undo the allocation done in the TX path when the station is in power-save mode. Signed-off-by: Nicolas Cavallari <cavallar@lri.fr> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 992d52529d7840236d3059b51c15d5eb9e81a869 upstream.

On Access Point mode, when transmitting a packet, if the destination
station is in powersave mode, we abort transmitting the packet to the
device queue, but we do not reclaim the allocated memory.  Given enough
packets, we can go in a state where there is no packet on the device
queue, but we think the device has no memory left, so no packet gets
transmitted, connections breaks and the AP stops working.

This undo the allocation done in the TX path when the station is in
power-save mode.

Signed-off-by: Nicolas Cavallari <cavallar@lri.fr>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>