kernel/linux.git/drivers/net/wireless, branch linux-2.6.35.y

ath5k: fix memory leak when fewer than N_PD_CURVES are in use

2011-08-01T20:54:57+00:00

commit a0b8de350be458b33248e48b2174d9af8a4c4798 upstream. We would free the proper number of curves, but in the wrong slots, due to a missing level of indirection through the pdgain_idx table. It's simpler just to try to free all four slots, so do that. Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

p54usb: add zoom 4410 usbid

2011-08-01T20:54:53+00:00

commit 9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream. Reported-by: Mark Davis Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

libertas: fix cmdpendingq locking

2011-08-01T20:54:48+00:00

commit 2ae1b8b35faba31a59b153cbad07f9c15de99740 upstream. We occasionally see list corruption using libertas. While we haven't been able to diagnose this precisely, we have spotted a possible cause: cmdpendingq is generally modified with driver_lock held. However, there are a couple of points where this is not the case. Fix up those operations to execute under the lock, it seems like the correct thing to do and will hopefully improve the situation. Signed-off-by: Paul Fox Signed-off-by: Daniel Drake Acked-by: Dan Williams Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

rt2500usb: fallback to SW encryption for TKIP+AES

2011-08-01T20:54:47+00:00

commit 75f64dd54a185150ebfc45e99351c890d4a2252f upstream. HW crypto in rt2500usb does not seem to support keys with different ciphers, which breaks TKIP+AES mode. Fall back to software encryption to fix it. This should fix long-standing problems with rt2500usb and WPA, such as: http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834 https://bugzilla.redhat.com/show_bug.cgi?id=484888 Also tested that it does not break WEP, TKIP-only and AES-only modes. Signed-off-by: Ondrej Zary Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Andi Kleen [bwh: Adjust context for 2.6.32] Signed-off-by: Greg Kroah-Hartman

iwlwifi: fix skb usage after free

2011-04-28T15:21:15+00:00

[AK: Did some changes for the backport to .35. Stanislaw, please verify them] Since commit a120e912eb51e347f36c71b60a1d13af74d30e83 Author: Stanislaw Gruszka Date: Fri Feb 19 15:47:33 2010 -0800 iwlwifi: sanity check before counting number of tfds can be free we use skb->data after calling ieee80211_tx_status_irqsafe(), which could free skb instantly. On current kernels I do not observe practical problems related with bug, but on 2.6.35.y it cause random system hangs when stressing wireless link. Cc: stable@kernel.org # 2.6.32+ Signed-off-by: Stanislaw Gruszka Signed-off-by: Andi Kleen

iwlagn: Support new 5000 microcode.

2011-04-28T15:21:14+00:00

commit 41504cce240f791f1e16561db95728c5537fbad9 upstream. New iwlwifi-5000 microcode requires driver support for API version 5. Signed-off-by: Don Fry Signed-off-by: Wey-Yi Guy Signed-off-by: Stanislaw Gruszka Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

p54: Initialize extra_len in p54_tx_80211

2011-04-28T15:21:11+00:00

commit a6756da9eace8b4af73e9dea43f1fc2889224c94 upstream. This patch fixes a very serious off-by-one bug in the driver, which could leave the device in an unresponsive state. The problem was that the extra_len variable [used to reserve extra scratch buffer space for the firmware] was left uninitialized. Because p54_assign_address later needs the value to reserve additional space, the resulting frame could be to big for the small device's memory window and everything would immediately come to a grinding halt. Reference: https://bugs.launchpad.net/bugs/722185 Acked-by: Christian Lamparter Signed-off-by: Jason Conti Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

ath: add missing regdomain pair 0x5c mapping

2011-04-28T15:21:10+00:00

commit bd39a274fb7b43374c797bafdb7f506598f36f77 upstream. Joe Culler reported a problem with his AR9170 device: > ath: EEPROM regdomain: 0x5c > ath: EEPROM indicates we should expect a direct regpair map > ath: invalid regulatory domain/country code 0x5c > ath: Invalid EEPROM contents It turned out that the regdomain 'APL7_FCCA' was not mapped yet. According to Luis R. Rodriguez [Atheros' engineer] APL7 maps to FCC_CTL and FCCA maps to FCC_CTL as well, so the attached patch should be correct. Reported-by: Joe Culler Acked-by: Luis R. Rodriguez Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

ath9k: fix a chip wakeup related crash in ath9k_start

2011-04-28T15:21:10+00:00

[ upstream commit f62d816fc4324afbb7cf90110c70b6a14139b225 ] When the chip is still asleep when ath9k_start is called, ath9k_hw_configpcipowersave can trigger a data bus error. Signed-off-by: Felix Fietkau Signed-off-by: Andi Kleen Cc: stable@kernel.org Signed-off-by: John W. Linville

b43: allocate receive buffers big enough for max frame len + offset

2011-04-28T15:20:54+00:00

commit c85ce65ecac078ab1a1835c87c4a6319cf74660a upstream. Otherwise, skb_put inside of dma_rx can fail... https://bugzilla.kernel.org/show_bug.cgi?id=32042 Signed-off-by: John W. Linville Acked-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen