aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/wireless/rt2x00
AgeCommit message (Collapse)Author
2014-12-14Merge tag 'driver-core-3.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core update from Greg KH: "Here's the set of driver core patches for 3.19-rc1. They are dominated by the removal of the .owner field in platform drivers. They touch a lot of files, but they are "simple" changes, just removing a line in a structure. Other than that, a few minor driver core and debugfs changes. There are some ath9k patches coming in through this tree that have been acked by the wireless maintainers as they relied on the debugfs changes. Everything has been in linux-next for a while" * tag 'driver-core-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (324 commits) Revert "ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries" fs: debugfs: add forward declaration for struct device type firmware class: Deletion of an unnecessary check before the function call "vunmap" firmware loader: fix hung task warning dump devcoredump: provide a one-way disable function device: Add dev_<level>_once variants ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries ath: use seq_file api for ath9k debugfs files debugfs: add helper function to create device related seq_file drivers/base: cacheinfo: remove noisy error boot message Revert "core: platform: add warning if driver has no owner" drivers: base: support cpu cache information interface to userspace via sysfs drivers: base: add cpu_device_create to support per-cpu devices topology: replace custom attribute macros with standard DEVICE_ATTR* cpumask: factor out show_cpumap into separate helper function driver core: Fix unbalanced device reference in drivers_probe driver core: fix race with userland in device_add() sysfs/kernfs: make read requests on pre-alloc files use the buffer. sysfs/kernfs: allow attributes to request write buffer be pre-allocated. fs: sysfs: return EGBIG on write if offset is larger than file size ...
2014-12-01Revert "rt2x00: Endless loop on hub port power down"Stanislaw Gruszka
This reverts commit 2ad69ac5976191e9bb7dc4044204a504653ad1bb. It causes wireless device disappear when we get -EPROTO error form USB request. I encounter such situation occasionally when resume form suspend with RT3070 adapter: [ 289.619985] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x06 failed for offset 0x0404 with error -71 [ 289.639368] ieee80211 phy0: rt2800_wait_bbp_ready: Error - BBP register access failed, aborting [ 289.639374] ieee80211 phy0: rt2800usb_set_device_state: Error - Device failed to enter state 4 (-5) Without the patch, except printing error, device works just fine after resume. Currently after timeouts and REGISTER_BUSY_COUNT tuning, we should not have any "endless loop", though we can wait quite long when driver is trying to communicate with the device through non functioning USB connection. Generally the problem that commit 2ad69ac597619 solves is kinda artificial. Cc: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-12-01rt2x00: change REGISTER_TIMEOUTStanislaw Gruszka
Waiting 500ms for register access is too long, decrease this value to 100ms. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-12-01rt2x00: change REGISTER_BUSY_COUNT for USBStanislaw Gruszka
Because of delays on USB we do not have to iterate so many times on USB hardware when waiting for H/W register become valid. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-12-01rt2x00: use timeout in rt2x00usb_vendor_requestStanislaw Gruszka
Use provided timeout value in rt2x00usb_vendor_request() instead of iterating REGISTER_BUSY_COUNT times. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-12-01rt2800: calculate tx power temperature compensation on selected chipsStanislaw Gruszka
Currently implemented temperature compensation is only valid on some of supported chips. Other chips do not need temperature compensation or need different way to do this (not yet implemented in the rt2800 driver). Trying to do run rt2800_get_gain_calibration_delta() when this is not appropriate on particular chip gives bogus result of TX power and can make connection unstable. This is follow up to commit 8c8d2017ba25c510ddf093419048460db1109bc4 "rt2800: fix RT5390 & RT3290 TX power settings regression". On that commit we avoid setting BBP_R1 register, but the real problem is wrong temperature compensation calculation. Reported-and-tested-by: Ronald Wahl <ronald.wahl@raritan.com> Debugged-by: Ronald Wahl <ronald.wahl@raritan.com> Cc: Mike Romberg <mike-romberg@comcast.net> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-20Merge tag 'mac80211-next-for-john-2014-11-20' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg <johannes@sipsolutions.net> says: "It has been a while since my last pull request, so we accumulated another relatively large set of changes: * TDLS off-channel support set from Arik/Liad, with some support patches I did * custom regulatory fixes from Arik * minstrel VHT fix (and a small optimisation) from Felix * add back radiotap vendor namespace support (myself) * random MAC address scanning for cfg80211/mac80211/hwsim (myself) * CSA improvements (Luca) * WoWLAN Net Detect (wake on network found) support (Luca) * and lots of other smaller changes from many people" Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-19Merge commit '4e6ce4dc7ce71d0886908d55129d5d6482a27ff9' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-11-19mac80211: allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDRJohannes Berg
Allow drivers to support NL80211_SCAN_FLAG_RANDOM_ADDR with software based scanning and generate a random MAC address for them for every scan request with the flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-11-11rt2x00: do not align payload on modern H/WStanislaw Gruszka
RT2800 and newer hardware require padding between header and payload if header length is not multiple of 4. For historical reasons we also align payload to to 4 bytes boundary, but such alignment is not needed on modern H/W. Patch fixes skb_under_panic problems reported from time to time: https://bugzilla.kernel.org/show_bug.cgi?id=84911 https://bugzilla.kernel.org/show_bug.cgi?id=72471 http://marc.info/?l=linux-wireless&m=139108549530402&w=2 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591 Panic happened because we eat 4 bytes of skb headroom on each (re)transmission when sending frame without the payload and the header length not being multiple of 4 (i.e. QoS header has 26 bytes). On such case because paylad_aling=2 is bigger than header_align=0 we increase header_align by 4 bytes. To prevent that we could change the check to: if (payload_length && payload_align > header_align) header_align += 4; but not aligning payload at all is more effective and alignment is not really needed by H/W (that has been tested on OpenWrt project for few years now). Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi> Debugged-by: Antti S. Lankila <alankila@bel.fi> Reported-by: Henrik Asp <solenskiner@gmail.com> Originally-From: Helmut Schaa <helmut.schaa@googlemail.com> Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-11-03Merge branch 'platform/remove_owner' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux into driver-core-next Remove all .owner fields from platform drivers
2014-10-30wireless: rt2x00: add new rt2800usb deviceCyril Brulebois
0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle References: https://bugs.debian.org/766802 Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz> Cc: stable@vger.kernel.org Signed-off-by: Cyril Brulebois <kibi@debian.org> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-27rt2x00: tune multi-registers I/O timeoutStanislaw Gruszka
We provide timeout value to rt2x00usb_vendor_request_buff() based on number of registers to process. That value is passed down to rt2x00usb_vendor_req_buff_lock() and ends in usb_control_msg(). But we do not read/write all registers in rt2x00usb_vendor_req_buff_lock() at once. We read/write them in chunks of 64 bytes in the loop, hence passed timeout value to low level is too big. Patch removes timeout argument from rt2x00usb_vendor_request_buff() and use short REGISTER_TIMEOUT in rt2x00usb_vendor_req_buff_lock(). That timeout value should be fine for 64 bytes and smaller requests. For EEPROM read we introduced new timeout value equal to 2 seconds. Patch fixes process uninterruptible sleep stalls for long period, when USB bus has problem to satisfy a request and we wait very long time on usb_start_wait_urb(). Reported-and-tested-by: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-10-20net: wireless: rt2x00: drop owner assignment from platform_driversWolfram Sang
A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2014-09-26rt2800: correct BBP1_TX_POWER_CTRL maskStanislaw Gruszka
Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-08-28rt2x00: support Ralink 5362.Canek Peláez Valdés
Signed-off-by: Canek Peláez Valdés <canek@ciencias.unam.mx> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-08-12PCI: Remove DEFINE_PCI_DEVICE_TABLE macro useBenoit Taine
We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines. This issue was reported by checkpatch. A simplified version of the semantic patch that makes this change is as follows (http://coccinelle.lip6.fr/): // <smpl> @@ identifier i; declarer name DEFINE_PCI_DEVICE_TABLE; initializer z; @@ - DEFINE_PCI_DEVICE_TABLE(i) + const struct pci_device_id i[] = z; // </smpl> [bhelgaas: add semantic patch] Signed-off-by: Benoit Taine <benoit.taine@lip6.fr> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-07-15wireless: rt2x00: add new rt2800usb devicesXose Vazquez Perez
0x0b05 0x17e8 RT5372 USB 2.0 bgn 2x2 ASUS USB-N14 0x0411 0x0253 RT5572 USB 2.0 abgn 2x2 BUFFALO WLP-U2-300D 0x0df6 0x0078 RT???? Sitecom N300 Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: John W. Linville <linville@tuxdriver.com> Cc: users@rt2x00.serialmonkey.com Cc: linux-wireless@vger.kernel.org Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-07-10Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-07-07rt2800usb: Don't perform DMA from stackAndrea Merello
Function rt2800usb_autorun_detect() passes the address of a variable allocated onto the stack to be used for DMA by the USB layer. This has been caught by my debugging-enabled kernel. This patch change things in order to allocate that variable via kmalloc, and it adjusts things to handle the kmalloc failure case, propagating the error. [ 7363.238852] ------------[ cut here ]------------ [ 7363.243529] WARNING: CPU: 1 PID: 5235 at lib/dma-debug.c:1153 check_for_stack+0xa4/0xf0() [ 7363.251759] ehci-pci 0000:00:04.1: DMA-API: device driver maps memory fromstack [addr=ffff88006b81bad4] [ 7363.261210] Modules linked in: rt2800usb(O+) rt2800lib(O) rt2x00usb(O) rt2x00lib(O) rtl818x_pci(O) rtl8187 led_class eeprom_93cx6 mac80211 cfg80211 [last unloaded: rt2x00lib] [ 7363.277143] CPU: 1 PID: 5235 Comm: systemd-udevd Tainted: G O 3.16.0-rc3-wl+ #31 [ 7363.285546] Hardware name: System manufacturer System Product Name/M3N78 PRO, BIOS ASUS M3N78 PRO ACPI BIOS Revision 1402 12/04/2009 [ 7363.297511] 0000000000000009 ffff88006b81b710 ffffffff8175dcad ffff88006b81b758 [ 7363.305062] ffff88006b81b748 ffffffff8106d372 ffff88006cf10098 ffff88006cead6a0 [ 7363.312622] ffff88006b81bad4 ffffffff81c1e7c0 ffff88006cf10098 ffff88006b81b7a8 [ 7363.320161] Call Trace: [ 7363.322661] [<ffffffff8175dcad>] dump_stack+0x4d/0x6f [ 7363.327847] [<ffffffff8106d372>] warn_slowpath_common+0x82/0xb0 [ 7363.333893] [<ffffffff8106d3e7>] warn_slowpath_fmt+0x47/0x50 [ 7363.339686] [<ffffffff813a93b4>] check_for_stack+0xa4/0xf0 [ 7363.345298] [<ffffffff813a995c>] debug_dma_map_page+0x10c/0x150 [ 7363.351367] [<ffffffff81521bd9>] usb_hcd_map_urb_for_dma+0x229/0x720 [ 7363.357890] [<ffffffff8152256d>] usb_hcd_submit_urb+0x2fd/0x930 [ 7363.363929] [<ffffffff810eac31>] ? irq_work_queue+0x71/0xd0 [ 7363.369617] [<ffffffff810ab5a7>] ? wake_up_klogd+0x37/0x50 [ 7363.375219] [<ffffffff810ab7a5>] ? console_unlock+0x1e5/0x420 [ 7363.381081] [<ffffffff810abc25>] ? vprintk_emit+0x245/0x530 [ 7363.386773] [<ffffffff81523d3c>] usb_submit_urb+0x30c/0x580 [ 7363.392462] [<ffffffff81524295>] usb_start_wait_urb+0x65/0xf0 [ 7363.398325] [<ffffffff815243ed>] usb_control_msg+0xcd/0x110 [ 7363.404014] [<ffffffffa005514d>] rt2x00usb_vendor_request+0xbd/0x170 [rt2x00usb] [ 7363.411544] [<ffffffffa0074292>] rt2800usb_autorun_detect+0x32/0x50 [rt2800usb] [ 7363.418986] [<ffffffffa0074aa1>] rt2800usb_read_eeprom+0x11/0x70 [rt2800usb] [ 7363.426168] [<ffffffffa0063ffd>] rt2800_probe_hw+0x11d/0xf90 [rt2800lib] [ 7363.432989] [<ffffffffa0074b7d>] rt2800usb_probe_hw+0xd/0x50 [rt2800usb] [ 7363.439808] [<ffffffffa00453d8>] rt2x00lib_probe_dev+0x238/0x7c0 [rt2x00lib] [ 7363.446992] [<ffffffffa00bfa48>] ? ieee80211_led_names+0xb8/0x100 [mac80211] [ 7363.454156] [<ffffffffa0056116>] rt2x00usb_probe+0x156/0x1f0 [rt2x00usb] [ 7363.460971] [<ffffffffa0074250>] rt2800usb_probe+0x10/0x20 [rt2800usb] [ 7363.467616] [<ffffffff8152799e>] usb_probe_interface+0xce/0x1c0 [ 7363.473651] [<ffffffff81480c20>] really_probe+0x70/0x240 [ 7363.479079] [<ffffffff81480f01>] __driver_attach+0xa1/0xb0 [ 7363.484682] [<ffffffff81480e60>] ? __device_attach+0x70/0x70 [ 7363.490461] [<ffffffff8147eef3>] bus_for_each_dev+0x63/0xa0 [ 7363.496146] [<ffffffff814807c9>] driver_attach+0x19/0x20 [ 7363.501570] [<ffffffff81480468>] bus_add_driver+0x178/0x220 [ 7363.507270] [<ffffffff8148151b>] driver_register+0x5b/0xe0 [ 7363.512874] [<ffffffff815271b0>] usb_register_driver+0xa0/0x170 [ 7363.518905] [<ffffffffa007a000>] ? 0xffffffffa0079fff [ 7363.524074] [<ffffffffa007a01e>] rt2800usb_driver_init+0x1e/0x20 [rt2800usb] [ 7363.531247] [<ffffffff810002d4>] do_one_initcall+0x84/0x1b0 [ 7363.536932] [<ffffffff8113aa60>] ? kfree+0xd0/0x110 [ 7363.541931] [<ffffffff8112730a>] ? __vunmap+0xaa/0xf0 [ 7363.547538] [<ffffffff810ca07e>] load_module+0x1aee/0x2040 [ 7363.553141] [<ffffffff810c6f10>] ? store_uevent+0x50/0x50 [ 7363.558676] [<ffffffff810ca66e>] SyS_init_module+0x9e/0xc0 [ 7363.564285] [<ffffffff81764012>] system_call_fastpath+0x16/0x1b [ 7363.570338] ---[ end trace 01ef5f822bea9882 ]--- Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19drivers/net/wireless/rt2x00/rt2x00dev.c: remove null test before kfreeFabian Frederick
Fix checkpatch warning: WARNING: kfree(NULL) is safe this check is probably not required Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19rt2x00: Use dma_zalloc_coherentJoe Perches
Use the zeroing function instead of dma_alloc_coherent & memset(,0,) Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19rt2x00: do not initialize BCN_OFFSET registersStanislaw Gruszka
We setup BCN_OFFSET{0,1} registers dynamically, don't have to initialize them. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19rt2x00: change order when stop beaconingStanislaw Gruszka
When no beaconing is needed, first stop beacon queue (disable beaconing globally) to avoid possible sending of not prepared beacon on short period after clearing beacon and before stop of BCN queue. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19rt2x00: change default MAC_BSSID_DW1_BSS_BCN_NUMStanislaw Gruszka
We setup MAC_BSSID_DW1_BSS_BCN_NUM dynamically when numbers of active beacons increase. Change default to 0 to tell hardware that we want to send only one beacon as default. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19rt2x00: change beaconing setup on RT2800Stanislaw Gruszka
As reported by Matthias, on 5572 chip, even if we clear up TXWI of corresponding beacon, hardware still try to send it or do other action that increase power consumption peak up to 1A. To avoid the issue, setup beaconing dynamically by configuring offsets of currently active beacons and MAC_BSSID_DW1_BSS_BCN_NUM variable, which limit number of beacons that hardware will try to send. Reported-by: Matthias Fend <Matthias.Fend@wolfvision.net> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19rt2x00: change beaconing lockingStanislaw Gruszka
This patch is needed for further changes to keep global variables consistent when changing beaconing on diffrent vif's. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-19net: wireless: rt2x00: rt2x00mac.c: Cleaning up uninitialized variablesRickard Strandqvist
There is a risk that the variable will be used without being initialized. This was largely found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-17rt2x00: fix rfkill regression on rt2500pciStanislaw Gruszka
As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5f3cb8 ("rt2x00: Fix rfkill_polling register function.") Cc: stable@vger.kernel.org Bisected-by: Niels <nille0386@googlemail.com> Reported-and-tested-by: Niels <nille0386@googlemail.com> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-17rt2800usb:fix hang during firmware loadMichael Braun
The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) boots into a state that does not actually require loading a firmware file. The vendors driver finds out about this by checking a firmware state register, so this patch adds this here. Finally, with this patch applied, my wifi dongle actually becomes useful (scan + connect to wpa network works). Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-17rt2800usb:fix efuse detectionMichael Braun
The device 057c:8501 (AVM Fritz! WLAN v2 rev. B) currently does not load. One thing observed is that the vendors driver detects EFUSE mode for this device, but rt2800usb does not. This is due to rt2800usb lacking a check for the firmware mode present in the vendors driver, that this patch adopts for rt2800usb. With this patch applied, the 'RF chipset' detection does no longer fail. Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-06-16rt2x00: disable TKIP on USBStanislaw Gruszka
On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 <snip> [ 860.827280] Call Trace: [ 860.827282] [<ffffffff81682ea6>] dump_stack+0x4d/0x66 [ 860.827284] [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55 [ 860.827285] [<ffffffff81685bb3>] __schedule+0x733/0x7b0 [ 860.827287] [<ffffffff81685c59>] schedule+0x29/0x70 [ 860.827289] [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0 [ 860.827291] [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70 [ 860.827296] [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20 [ 860.827301] [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110 [ 860.827305] [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211] Cc: stable@vger.kernel.org Reported-and-tested-by: Peter Wu <lekensteyn@gmail.com> Reported-and-tested-by: Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-05-22rt2x00: Endless loop on hub port power downRichard Genoud
I've met an endless (or at least very long) loop if I power down the usb port on witch a usb wifi key is plugged. (Ok, it's not very smart to power down a usb port when a usb key is in used... but still, I think that should not lead to an endless loop). I have a lot of: ieee80211 phy1: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71 (-71==-EPROTO) How to reproduce: - plug an usb wifi key - ip link set wlan0 up - hub-ctrl -b usb_bus -d usb_device -P usb_port -p 0 hub-ctrl source: https://github.com/codazoda/hub-ctrl.c/blob/master/hub-ctrl.c The following patch prevents the endless loop, but I'm really not sure that The Right Way To Do It (R) Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-05-13Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-04-30Merge branch 'for-john' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Conflicts: net/mac80211/chan.c
2014-04-22rt2x00: restore original beaconing stateStanislaw Gruszka
After changing local per interface beacon setting restore original global beaconing state. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-22rt2x00: fix beaconing on USBStanislaw Gruszka
When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Cc: stable@vger.kernel.org Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-04-09mac80211: add vif to flush callEmmanuel Grumbach
This will allow the low level driver to make decision based on the vif such as queues etc... Since the vif might be NULL, we can't add it to the tracing functions. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [fix staging rtl8821ae driver] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-03-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Conflicts: Documentation/devicetree/bindings/net/micrel-ks8851.txt net/core/netpoll.c The net/core/netpoll.c conflict is a bug fix in 'net' happening to code which is completely removed in 'net-next'. In micrel-ks8851.txt we simply have overlapping changes. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-13Revert "rt2x00: rt2800lib: Update BBP register initialization for RT53xx"Stanislaw Gruszka
This reverts commit eac40d9631a7db43570df859fa8a9922e9623607. It cause random connection drops on RT5390 PCI adapters. On Mediatek there is different driver version available for RT53xx chip based on bus type (2.5.0.3 for PCI and 2.6.1.3 for USB). Hence possibly we should set registers differently based on bus type. But is also possible that new driver (i.e. 2.6.1.3) was not verified on RT53xx USB. Until we figure out how to initialize registers properly for RT53xx just revert commit eac40d9631a7db43570df859fa8a9922e9623607 since it cause regression. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-03-03net: Replace min macro with min_tSilvan Jegen
Instead of an explicit cast, use the min_t macro. Signed-off-by: Silvan Jegen <s.jegen@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-24wireless/rt2x00: don't use PREPARE_WORK in rt2800usb.cTejun Heo
PREPARE_[DELAYED_]WORK() are being phased out. They have few users and a nasty surprise in terms of reentrancy guarantee as workqueue considers work items to be different if they don't have the same work function. Update rt2800usb.c to use INIT_WORK() instead of PREPARE_WORK(). As the work item isn't in active use during rt2800usb_probe_hw(), this doesn't cause any behavior difference. It would probably be best to route this with other related updates through the workqueue tree. Only compile tested. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Gertjan van Wingerde <gwingerde@gmail.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: linux-wireless@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-13Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
2014-02-12rt2x00: move frequent messages to debug levelStanislaw Gruszka
On commit 28f2bce9f8bbf704c86f8c684337f82c51592c81 I make change that print various messages as default. This can cause flood of messages related to TX status timeout on some environments. I partially fixed problem on commit bb9c298f3193ac5b80e47b325c690700580b6bcf, but forgot to move two more messages to debug level. 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>
2014-02-04rt2500: disable PS by defaultStanislaw Gruszka
It is know that PS cause issues on that old devices, disable it by default. 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>
2014-02-04rt2800: disable PS by default on USBStanislaw Gruszka
We have disabled it currently on other buses. PS can cause some issues, not necessarily with our driver but on AP, that are not easy to debug. Since behaviour differs on rt2800usb and rt2800pci, user usually blame for malfunction rt2800usb driver, whereas issue is on AP side. 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>
2014-01-23rt2x00: rt2800usb: mark D-Link DWA-137 as supportedRoman Dubtsov
Signed-off-by: Roman Dubtsov <dubtsov@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-01-03wireless: delete non-required instances of include <linux/init.h>Paul Gortmaker
None of these files are actually using any __init type directives and hence don't need to include <linux/init.h>. Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Christian Lamparter <chunkeey@googlemail.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-01-03rt2x00: use ether_addr_equal_64bitsJulia Lawall
Ether_addr_equal_64bits is more efficient than ether_addr_equal, and can be used when each argument is an array within a structure that contains at least two bytes of data beyond the array. The structures involved are: ieee80211_bar defined in include/linux/ieee80211.h and rt2x00_bar_list_entry defined in drivers/net/wireless/rt2x00/rt2x00.h. This was done using Coccinelle (http://coccinelle.lip6.fr/). Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2013-12-11rt2x00: Fix FSF address in file headersJeff Kirsher
Several files refer to an old address for the Free Software Foundation in the file header comment. Resolve by replacing the address with the URL <http://www.gnu.org/licenses/> so that we do not have to keep updating the header comments anytime the address changes. CC: linux-wireless@vger.kernel.org CC: Ivo van Doorn <IvDoorn@gmail.com> CC: Gertjan van Wingerde <gwingerde@gmail.com> CC: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>