(based on an earlier patch submitted by Shiang)

Add support for RT3572/RT3592/RT3592+Bluetooth combo card
Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

(split off from the earlier RT35xx patch submitted by Shiang)
Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

(split off from the earlier RT35xx patch submitted by Shiang)

There's no point in enabling the PA_PE bits for the bands that we are
not active on.
Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We make oldconfig every time when a new kernel arrives, but
if we don't have such a device(I guess this is the most common
case for a new device), the default value should be 'n' so
that the kernel size we build doesn't grow up too much quickly.
For anyone who has the device, it is OK for them to turn it on
by themselves.

Cc: "John W. Linville" <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NTao Ma <boyu.mt@taobao.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

txstatus_timer should only be deleted for USB devices, as it is only
initialized for USB devices.
Reported-by: NAndreas Hartmann <andihartmann@01019freenet.de>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Patch:
  rt2x00: Make rt2x00_queue_entry_for_each more flexible
  commit: 10e11568

introduced a severe regression on the throughput
for USB hardware. It turns out that the exiting of
the rt2x00queue_for_each_entry() was done too early.

The exact cause for this regression is unknown,
but by disabling the premature exiting of the loop
seems to resolve the issue.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Reported-by: NYasushi SHOJI <yashi@atmark-techno.com>
Reported-by: NBalint Viragh <bviragh@dension.com>
Tested-by: NBalint Viragh <bviragh@dension.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add necessary RF chipset define and basic support for these devices.
Tested-by: NJuan Carlos Garza <juancarlosgarza@gmail.com>
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The USB drivers don't support automatically waking up when in powersaving mode,
add a work object which will wakeup the device in time to receive the next beacon.
Based on that beacon, we either go back into powersaving mode, or we remain awake
to receive the buffered frames for our station.

Some part of the code, especially rt2x00lib_find_ie and rt2x00lib_rxdone_check_ps
are inspired on the code from carl9170.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use flag instead of re-reading the eeprom every time.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In rt2800lib.c the rt2800_init_eeprom function the same eeprom
words were read multiple times, due to inefficient ordering of the
eeprom checks.

Reorder the checks so that each EEPROM word only has to be read once.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch
	rt2x00: Optimize register access in rt2800pci
from Helmut Schaa missed one register call, namely
the rt2800_register_multiwrite which should be changed
to rt2x00pci_register_multiwrite.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add recycling functionality to rt2x00usb_register_read_async.
When the callback function returns true, resubmit the urb to
read the register again.

This optimizes the rt2800usb driver when multiple TX status reports
are pending in the register, because now we don't need to allocate
the rt2x00_async_read_data and urb structure each time.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When no TX status was available, the default timeout
of 20ms is a bit high. The frame is highly likely already
send out, so the TX status should be available within
only a few milliseconds.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Implement the get_antenna and set_antenna callback functions, which will
allow clients to control the antenna for all non-11n hardware (Antenna handling
in rt2800 is still a bit magical, so we can't use the set_antenna for those drivers
yet).

To best support the set_antenna callback some modifications are needed in the
diversity handling. We should never look at the default antenna settings to determine
if software diversity is enabled. Instead we should set the diversity flag when
possible, which will allow the link_tuner to automatically pick up the tuning.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With the get_ringparam callback function we can export ring parameters
to ethtool through the mac80211 interface.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All register reads/writes in rt2800usb were previously done with
rt2800_register_read/rt2800_register_write. These however indirectly
call rt2x00usb_register_read/rt2x00usb_register_write which adds an
additional overhead of at least one call and several move instructions
to each register access.

Replacing the calls to rt2800_register_read/rt2800_register_write with
direct calls to rt2x00usb_register_read/rt2x00usb_register_write gets
rid of quite a number of instructions in the drivers hotpaths (IRQ
handling and txdone handling).

For consistency replace all references to rt2800_register_read/write
with the rt2x00usb_register_read/write variants.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All register reads/writes in rt2800pci were previously done with
rt2800_register_read/rt2800_register_write. These however indirectly
call rt2x00pci_register_read/rt2x00pci_register_write which adds an
additional overhead of at least one call and several move instructions
to each register access.

Replacing the calls to rt2800_register_read/rt2800_register_write with
direct calls to rt2x00pci_register_read/rt2x00pci_register_write gets
rid of quite a number of instructions in the drivers hotpaths (IRQ
handling and txdone handling).

For consistency replace all references to rt2800_register_read/write
with the rt2x00pci_register_read/write variants.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The two functions that are in rt2x00ht.c can be much better placed
closer to the places where the call-sites of these functions are (one
in rt2x00config.c and one in rt2x00queue.c) allowing us to make these
functions static.
Also, conditional compilations doesn't seem to be necessary anymore as
802.11n support is quite common nowadays.

This makes the code a bit easier readable and searchable.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Code seems to be feature-complete, so no reason to not enable
these devices by default.

Also, remove the sentence about the support for these devices being
non-functional.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The rt33xx devices support for both PCI and USB devices has been in
the tree for a couple of months now, and seems to be functional and
not in a worse shape than the support for rt28xx and rt30xx devices.

No longer mark it as experimental and enable the support for these
devices by default.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add USB IDs that are listed in the latest Ralink Windows and/or Linux drivers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Both USB and PCI drivers allow a system administrator to dynamically add
USB/PCI IDs to the device table that a driver supports via the
/sys/bus/{usb,pci,pci_express}/drivers/<driver-name>/new_id files.

However, for the rt2x00 drivers using this method currently crashes the
system with a NULL pointer failure.

This is due to the set-up of rt2x00 where the probe functions require a
rt2x00_ops structure in the driver_info field of the probed device. As
this field is empty for the dynamically added devices this fails for
these devices.

Fix this by introducing driver-specific probe wrappers that do nothing
but calling the bus-specific probe functions with the rt2x00_ops structure
as an argument, rather than depending on the driver_info field.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move the USB ID entry from the unknown devices to the list of RT35xx based
devices.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This allows the compiler to perform the necessary bitfield calculations
during compile time instead of run time and thus reduces the number of
instructions to run during each tasklet invocation. This should improve
performance in the RX hotpath.

This comes at the cost of a slight increase in the module size (for
example rt2800pci):

Before:
   text    data     bss     dec     hex filename
  14133     832       4   14969    3a79 drivers/net/wireless/rt2x00/rt2800pci.ko

After:
   text    data     bss     dec     hex filename
  14149     832       4   14985    3a89 drivers/net/wireless/rt2x00/rt2800pci.ko
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When powersaving is enabled, assocaition times are very high
(for WPA2 networks, the time can easily be around the 3 seconds).

This is caused, because the flushing of the queues takes
too much time. Without the flushing callback mac80211 assumes
a timeout of 100ms while scanning. Limit all flush waiting
loops to the same maximum.

We can apply this maximum by passing the drop status to the
driver, which makes sure the driver performs extra actions
during the waiting for the queue to become empty.

After these changes, association times fall within the
healthy range of ~0.6 seconds with powersaving enabled.
The difference between association time between powersaving
enabled and disabled is now only ~0.1 second (which can also
be due to the measuring method).
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TX status is reported by the hardware when a packet has been
sent (or after TX failed after possible retries), which is some
time after the DMA completion.  Since the rt2800usb hardware can
not signal interrupts we have to use a timer, otherwise the
TX status would only be read by the next packet's TX DMA
completion, or by the watchdog thread.
Signed-off-by: NJohannes Stezenbach <js@sig21.net>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The watchdog just triggers rt2800usb_work_txdone() when it
detects a TX status timeout, thus rt2800usb_work_txdone() needs to
handle this case.
Signed-off-by: NJohannes Stezenbach <js@sig21.net>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add a timestamp to each queue entry which is updated whenever
the status of the entry changes, and remove the per-queue
timestamps.  The previous check was incorrect and caused both
false positives and false negatives.

With the corrected check it comes apparent that the TX status
usually times out on rt2800usb unless there is sufficient traffic
(i.e. the next TX will complete the previous TX status).
Signed-off-by: NJohannes Stezenbach <js@sig21.net>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Trying to fix the "TX status report missed" warnings
by reading the TX_STA_FIFO entries as quickly as possible.
The TX_STA_FIFO is too small in hardware, thus reading
it only from the workqueue is too slow and entries get lost.

Start an asynchronous read of the TX_STA_FIFO directly from
the TX URB completion callback (atomic context, thus it cannot
use the blocking rt2800_register_read()). If the async
read returns a valid FIFO entry, it is pushed into a larger
FIFO inside struct rt2x00_dev, until rt2800_txdone() picks
it up.

A .tx_dma_done callback is added to struct rt2x00lib_ops
to trigger the async read from the URB completion callback.
Signed-off-by: NJohannes Stezenbach <js@sig21.net>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use TXOP_HTTXOP for beacons to stay in sync with the legacy drivers.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Bring the TX_SW_CFG2 initialisation for rt305x devices in sync with the
ralink legacy drivers.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This seems to fix problems with some powersaving clients since a
positive value in TBTT_SYNC_CFG_TBTT_ADJUST introduces beacon skew,
which is not wanted in AP mode.

Also update the rest of the TBTT_SYNC config according to the
legacy drivers in AP mode.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allow passing a void pointer to rt2x00_queue_entry_for_each which in
turn in provided to the callback function.

Furthermore, allow the callback function to stop processing by returning
true. And also notify the caller of rt2x00_queue_entry_for_each if the
loop was canceled by the callback.

No functional changes, just preparation for an upcoming patch.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The number of flags defined for the rt2x00dev->flags field,
has been growing over the years. Currently we are approaching
the maximum number of bits which are available in the field.

A secondary problem, is that one part of the field are initialized only
during boot, because the driver requirements are initialized or device
requirements are loaded from the EEPROM. In both cases, the flags are
fixed and will not change during device operation. The other flags are
the device state, and will change frequently. So far this resulted in the fact
that for some flags, the atomic bit accessors are used, while for the others
the non-atomic variants are used.

By splitting the flags up into a "flags" and "cap_flags" we can put all flags
which are fixed inside "cap_flags". This field can then be read non-atomically.
In the "flags" field we keep the device state, which is going to be read atomically.

This adds more room for more flags in the future, and sanitizes the field access methods.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since commit 0b7fde54 "rt2x00: Protect
queue control with mutex" rt2x00 used rt2x00queue_pause_queue for
stopping a tx queue in mac80211. But in case of a failure in the tx
path rt2x00 still called ieee80211_stop_queue which stopped the queue
but prevented rt2x00queue_unpause_queue to wake the queue up again
resulting in a stuck tx queue.

Fix this by also using rt2x00queue_pause_queue in case of tx failures.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds WLAN LED support to the mac80211 rt2x00 driver for
Ralink SoC (rt305x) devices.  The current WLAN LED drivers in
rt2800lib.c set the LED brightness via an MCU request, but do nothing
for SoC.  This patch checks for SoC and sets the register to enable the
WLAN LED (instead of an MCU request).  This enables the WLAN LED for
RT305x devices.
Signed-off-by: NLayne Edwards <ledwards@astrumtech.net>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adds USB IDs for seven previously missing devices. Additionally, all
instances of 'Conceptronic' have been replaced by the OEM name.

Devices added are..
0411:01a2 - Buffalo WLI-UC-GNM, RT3070V
0586:341e - ZyXEL NWD2105, RT3070
13b1:002f - Linksys AE1000, RT3572
13b1:0031 - Cisco / Linksys AM10, RT3072
14b2:3c2c - Keebox W150NU / Alpha Networks WUS-N12, RT3070
157e:3013 - TRENDnet TEW-645UB, RT2770+RT2720
15a9:0012 - Airlink AWLL7025 / Gemtek WUBR-208N, RT2870+RT2850
Signed-off-by: NMark Davis <marked86@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The kernel already prints its build timestamp during boot, no need to
repeat it in random drivers and produce different object files each
time.
Signed-off-by: NMichal Marek <mmarek@suse.cz>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

based on the Ralink drivers:

W = Windows_ralink_driver
L = Linux_ralink_driver

USB_IDs         W_73  W_2500 L_73  L_2500
=============   ====  ====== ====  ======
0x050d,0x7050   -     -      -     YES
0x050d,0x705a   -     -      YES   -
0x1371,0x9022   -     YES    YES   -
0x148f,0x2573   YES   -      YES   -
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We already tell mac80211 to stop the queue when we hit a certain
threshold. Hence, it shouldn't happen at all that a frame gets queued
for tx on a full queue. Add an error message for this case.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>