linux/drivers/net/wireless/rt2x00, branch v3.2.46

rt2x00: rt2x00pci_regbusy_read() - only print register access failure once

2013-04-25T19:25:31Z

commit 83589b30f1e1dc9898986293c9336b8ce1705dec upstream. BugLink: http://bugs.launchpad.net/bugs/1128840 It appears that when this register read fails it never recovers, so I think there is no need to repeat the same error message ad infinitum. Cc: Ivo van Doorn Cc: Gertjan van Wingerde Cc: Helmut Schaa Cc: "John W. Linville" Cc: linux-wireless@vger.kernel.org Cc: users@rt2x00.serialmonkey.com Cc: netdev@vger.kernel.org Signed-off-by: Tim Gardner Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

rt2x00: error in configurations with mesh support disabled

2013-04-10T02:20:08Z

commit 6ef9e2f6d12ce9e2120916804d2ddd46b954a70b upstream. If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising interface combinations with NL80211_IFTYPE_MESH_POINT present. Add appropriate ifdefs to avoid running into errors. Signed-off-by: Felix Fietkau Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville [lxiang: Backported for 3.4-stable. Removed code of simultaneous AP and mesh mode added in 4a5fc6d 3.9-rc1.] Signed-off-by: Lingzhu Xiang Reviewed-by: CAI Qian Signed-off-by: Ben Hutchings

rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter

2013-02-20T03:15:27Z

commit fd7b9270120ca7e53fbf0469febe0c68acf6a0a2 upstream. D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a Ralink chipset supported by the rt2800usb driver. Currently, to work around the problem (it's missing in all present kernel versions, up to and including 3.7.x), I had to add this to /etc/rc.local: echo 2001 3c1e >> /sys/bus/usb/drivers/rt2800usb/new_id After that, the device works without problems. Been using it for over a week with no bugs in sight. The attached patch is trivial and simply adds the new USB ID to the list of devices handled by rt2800usb. Signed-off-by: Maia Kozheva Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

Wireless: rt2x00: Add device id for Sweex LW323 to rt2800usb.c

2013-02-20T03:15:27Z

commit 36f318bb124b231c01db6965a009f46d5731f012 upstream. This patch adds detection for the Sweex LW323 USB wireless network card in the rt2x00 driver (just one line in rt2800usb.c). It applies to linux-3.7-rc3. Signed-off-by: Jaume Delclòs Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

wireless: rt2x00: rt{2500,73}usb.c put back duplicate id

2013-02-20T03:15:27Z

commit 8f35f787b75e9b6435ea37dabcae2d40dc72d31c upstream. put back 0x050d,0x7050 to rt73usb, same usb_id for two chips: K7SF5D7050A ver 2xxx is rt2500 K7SF5D7050B ver 3xxx is rt73 Signed-off-by: Xose Vazquez Perez Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"

2013-01-16T01:13:23Z

commit ab9d6e4ffe192427ce9e93d4f927b0faaa8a941e upstream. This revert: commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f Author: Andreas Hartmann Date: Tue Apr 17 00:25:28 2012 +0200 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails To fix problem workaround by above commit use IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for "mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch). Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828 Bisected-by: Francisco Pina Martins Signed-off-by: Stanislaw Gruszka Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

2013-01-16T01:13:22Z

commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream. There are connection stalls or very poor throughputs with rt2800 hardware using 802.11n in AP mode since patch "mac80211: retry sending failed BAR frames later instead of tearing down aggr"[1][2]. Since rt2800 hardware is not able to correctly report the tx status of BAR frames, this patch removes as workaround the existing error handling on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails. As a result, most wifi clients (aside from Intel STAs on Windows) instead will timeout now the reorder buffer and request the lost frame again. The correct solution would be, to tear down BA session on AP side. This patch was born on the basis of "[RFT] rt2x00: Tear down BA session on QoS frame failure"[3]. Thanks to Helmut Schaa for his support! [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304 [2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98 [3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569 Signed-off-by: Andreas Hartmann Acked-by: Helmut Schaa Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

rt2800: validate step value for temperature compensation

2012-11-16T16:47:01Z

commit bf7e1abe434ba9e22e8dc04a4cba4ab504b788b8 upstream. Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the EEPROM, but step is equal to 0xff. This results on ridiculous delta calculations and completely broke TX power settings. Reported-and-tested-by: Pavel Lucik Signed-off-by: Stanislaw Gruszka Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

rt2800usb: Added rx packet length validity check

2012-09-19T14:05:11Z

commit efd5d6b03bd9c9e0df646c56fb5f4f3e25e5c1ac upstream. On our system (ARM Cortex-M3 SOC running linux-2.6.33) frequent crashes were observed in the rt2800usb module because of the invalid length of the received packet (3392, 46920...). This patch adds the sanity check on the packet legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone() so that the bad packet condition would be noticed. The fix was tested on the latest compat-wireless-3.5.1-1-snpc. Signed-off-by: Sergei Poselenov Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings

rt2x00: Fix rfkill polling prior to interface start.

2012-09-19T14:05:10Z

commit a396e10019eaf3809b0219c966865aaafec12630 upstream. We need to program the rfkill switch GPIO pin direction to input at device initialization time, not only when the interface is brought up. Doing this only when the interface is brought up could lead to rfkill detecting the switch is turned on erroneously and inability to create the interface and bringing it up. Reported-and-tested-by: Andreas Messer Signed-off-by: Gertjan van Wingerde Acked-by: Ivo Van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings