lwn.git/drivers/net/wireless/rt2x00/rt2x00usb.c, branch docs-fixes

rt2x00: move under ralink vendor directory

2015-11-18T12:28:31+00:00

Part of reorganising wireless drivers directory and Kconfig. Signed-off-by: Kalle Valo

rt2x00: use helper to check capability/requirement

2015-01-07T08:41:42+00:00

Use rt2x00_has_cap_flag macro to check rt2x00dev->cap_flags. Signed-off-by: Fred Chou Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo

Revert "rt2x00: Endless loop on hub port power down"

2014-12-01T20:57:21+00:00

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 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville

rt2x00: change REGISTER_BUSY_COUNT for USB

2014-12-01T20:57:21+00:00

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 Signed-off-by: John W. Linville

rt2x00: use timeout in rt2x00usb_vendor_request

2014-12-01T20:57:20+00:00

Use provided timeout value in rt2x00usb_vendor_request() instead of iterating REGISTER_BUSY_COUNT times. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville

rt2x00: tune multi-registers I/O timeout

2014-10-27T18:16:13+00:00

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 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville

rt2x00: Endless loop on hub port power down

2014-05-22T18:04:36+00:00

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 Signed-off-by: John W. Linville

rt2x00: Fix FSF address in file headers

2013-12-11T15:56:19+00:00

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 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 CC: Gertjan van Wingerde CC: Helmut Schaa Signed-off-by: Jeff Kirsher Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville

rt2x00: do not pause queue on flush

2013-10-10T17:49:28+00:00

Pausing queue on flush make no sense since txdone procedure un-pause queue. Before flush procedure we have to assure queue is stopped, i.e. on receive path h/w RX is disabled, on transmit path queue is disabled in mac80211. That conditions are true except one function: rt2x00usb_watchdog_tx_dma(), so add stop/start queue there. Note stop/start queue can be racy if we do this from multiple paths, but currently we stop TX queues only on rt2x00lib_disable_radio(), which also stop/sync watchdog, hance we have no race condition. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville

rt2x00: Use more current logging styles, shrink object size

2013-04-22T19:20:26+00:00

Reduce object space ~2% using more current logging styles. Neaten and simplify logging macros. Use wiphy_ where appropriate. Coalesce formats. Convert ERROR/WARNING/INFO macros to rt2x00_ Convert EEPROM to rt2x00_eeprom_dbg Convert PROBE_ERROR to rt2x00_probe_err Convert DEBUG to rt2x00_dbg Convert EEPROM to rt2x00_eeprom_dbg $ size drivers/net/wireless/rt2x00/built-in.o* text data bss dec hex filename 245639 71696 69584 386919 5e767 drivers/net/wireless/rt2x00/built-in.o.new 240609 70096 68944 379649 5cb01 drivers/net/wireless/rt2x00/built-in.o.new.nodyndbg 240609 70096 68944 379649 5cb01 drivers/net/wireless/rt2x00/built-in.o.new.no_rt2x00_debug 249198 70096 70352 389646 5f20e drivers/net/wireless/rt2x00/built-in.o.old 249198 70096 70352 389646 5f20e drivers/net/wireless/rt2x00/built-in.o.old.nodyndbg 244222 70096 69712 384030 5dc1e drivers/net/wireless/rt2x00/built-in.o.old.no_rt2x00_debug Signed-off-by: Joe Perches Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville