All of the driver's kick_tx_queue callback functions treat the TX queue
for beacons in a special manner.
Clean this up by integrating the kicking of the beacon queue into the
write_beacon callback function, and let the generic code no longer call
the kick_tx_queue callback function when updating the beacon.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RXWI processing is exactly the same for rt2800pci and rt2800usb, so
make it common code.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TXWI writing is exactly the same for rt2800pci and rt2800usb, so
make it common code.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should simply follow what the hardware told us it has done.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove unused RXD_DESC_SIZE define and remove duplicated RXWI definitions
from rt2800.h.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should take the stripping of the IV into account for the txdesc->length
field.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Tested-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2800 devices use a different enumeration to specify what IFS values should
be used on frame transmission compared to the other rt2x00 devices. Hence,
create a new enum called txop that contains the valid values.

Furthermore use the appropriate txop values as found in the ralink drivers:
- TXOP_BACKOFF for management frames
- TXOP_SIFS for subsequent fragments in a burst
- TXOP_HTTXOP for all data frames
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Update channel initialization for the RF3052 chipset.
According to the Ralink drivers, the rt3x array must be
used for this chipset, rather then the rt2x array.

Furthermore RF3052 supports the 5GHz band, extend
the rt3x array with the 5GHz channels, and use them
for the RF3052 chip.
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 SIFS value is a constant and doesn't need to be updated on erp changes.
Furthermore the code used 10us for both, the OFDM SIFS and CCK SIFS time
which broke CTS protected 11g connections (see patch "rt2x00: rt2800: update
initial SIFS values" for details).
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently the CCK and OFDM SIFS value is set to 32us. This value is neither
used by the Ralink driver nor specified in 802.11.

Instead of using 10us for CCK SIFS (as defined in 802.11) use 16us like in the
Ralink drivers. And indeed using a SIFS value of 10us breaks connectivity with
11g + CTS protected connections. Add a comment to the code why we don't use 10us
for CCK SIFS value.

The OFDM SIFS value is set to 16us (as defined in 802.11 and also used by the
Ralink drivers).
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

And use it consistently in the chipset drivers.
Preparation for further clean ups.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Inspection of the Ralink vendor driver shows that the TX_BAND_CFG register
and BBP register 3 are about HT40- indication, not about HT40+ indication.
Inverse the meaning of these fields in the code.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that RT30xx support is at the same level as RT28xx support we can enable
these devices by default.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PCI specific code has been remove quite some time ago.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

0x07d1,0x3c17 D-Link Wireless N 150 USB Adapter DWA-125
0x1b75,0x3071 Ovislink Airlive WN-301USB
0x1d4d,0x0011 Pegatron Ralink RT3072 802.11b/g/n Wireless Lan USB Device
0x083a,0xf511 Arcadyan 802.11 USB Wireless LAN Card
0x13d3,0x3322 AzureWave 802.11 n/g/b USB Wireless LAN Card
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>

Update the rfcsr and bbp init code for SoC devices to match with the
latest Ralink driver.

To have better control over which values are used for the register
initialization create a new function rt2800_is_305x_soc which checks
for SoC interface type, the correct RT chipset and the correct RF
chipset. This is based on the assumption that all rt305x SoC devices
use a rt2872 and rf3020/rf3021/rf3022.

In case an unknown RF chipset is found on a SoC device with a rt2872
don't treat it as rt305x and just print a message.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>

Remove redundant check for RT2872.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Restore the rfcsr initialization for RT305x SoC devices which was removed
by "rt2x00: Finish rt3070 support in rt2800 register initialization.".

This fixes the rx path on SoC devices.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix a typo in a comment in rt2800.h. Instead of replacing the wrong
hexvalue (0x171c) with the correct one (0x1718) just use the appropriate
readable define.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Get closer to what the ralink driver does by setting the rf register 13
to tx_power2 during channel switch.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.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>

Disable HT40 support for now as it causes rx problems with HT40 capable
11n APs (when mac80211 enables HT40, rx is completely disfunctional).

Once the rt2800 HT code is capable of using HT40 we should enable the
flag again.

I only tested this patch with a rt305x SoC device, nevertheless the
patch disables HT40 also on PCI and USB rt2800 devices.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.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>

Applied common sense, no info from the manufacturer:

(0x8516, 0x2070) is RT2070
(0x8516, 0x2770) is RT2770
(0x8516, 0x2870) is RT2870
[...]
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>

0x0e66,0x0009 HWUN2 Hawking Technologies Hi-Gain Wireless-150N USB Adapter w/ Upgradable Antenna
0x0e66,0x000b HWDN2 Hawking Technologies Hi-Gain USB Wireless-150N Dish Adapter
0x0e66,0x0013 Hawking Technologies Hi-Gain Wireless-N USB Adapter
0x0e66,0x0017 Hawking Wireless-N Network Adapter
0x0e66,0x0018 Hawking Wireless-N Network Adapter

Hawking Technologies Technical Support guys say:

All our N adapters use the same chipset. Ralink RT 2870 chipset.
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2800pci used the callback write_tx_desc to write the tx descriptor but
also to update the txwi which is part of the dma mapped skb. Since the
memory was already DMA mapped _before_ the call to write_tx_desc the
device didn't get the txwi data at all or only sporadically.

The call order is basically as follows (from rt2x00queue.c):
1) write_tx_data
2) rt2x00queue_map_txskb
3) write_tx_desc

Hence, we shouldn't touch the skb in write_tx_desc anymore.

To fix this issue create a new rt2800pci_write_tx_data callback and use it
for updating the txwi _before_ the memory gets DMA mapped.

The tx descriptor is still written (as before) in write_tx_desc.

This patch allows basic TX on an rt305x soc device but I'm pretty sure
that it will fix pci based cards as well. I can associate just fine with
an AP now but I wasn't able to get a wpa secured connection working yet.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Extend the write_tx_data callback with a txdesc parameter to allow
access to the tx desciptor while preparing the tx data.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A very useful information was provided by Sitecom R&D guys:

Please find the information regarding our latest Ralink adapters below;

WL-302    -    VID: 0x0DF6,    PID: 0x002D    -    Ralink RT2771
WL-315    -    VID: 0x0DF6,    PID: 0x0039    -    Ralink RT2770
WL-319    -    VID: 0x182D,    PID: 0x0037    -    Ralink RT2860
WL-321    -    VID: 0x0DF6,    PID: 0x003B    -    Ralink RT2770
WL-324    -    VID: 0x0DF6,    PID: 0x003D    -    Ralink RT2870
WL-329    -    VID: 0x0DF6,    PID: 0x0041    -    Ralink RT3572
WL-343    -    VID: 0x0DF6,    PID: 0x003E    -    Ralink RT3070
WL-344    -    VID: 0x0DF6,    PID: 0x0040    -    Ralink RT3071
WL-345    -    VID: 0x0DF6,    PID: 0x0042    -    Ralink RT3072
WL-608    -    VID: 0x0DF6,    PID: 0x003F    -    Ralink RT2070

Note:
PID: 0x003C, 0x004A, and 0x004D:   --these products do not exist; devices were never produced/shipped--

The WL-349v4 USB dongle (0x0df6,0x0050) will be shipped soon (it isn't available yet), and uses a Ralink RT3370 chipset.
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add RT3390 specific register initializations to rt2x00, based on the latest
Ralink rt3390 vendor driver.

Untested as I don't actually own an RT3390 based device, but given experiences
on rt3070/rt3071 very hopeful that this will actually work..
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add RT3090 specific register initializations to rt2x00, based on the latest
Ralink rt3090 vendor driver.

Untested as I don't actually own an RT3090 based device, but given experiences
on rt3070/rt3071 very hopeful that this will actually work..
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add RT3071 specific register initializations to rt2x00, based on the latest
Ralink rt3070 vendor driver.

With this patch my RT3071 based devices start showing a sign of life.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2x00 had preliminary support for RT3070 based devices, but the support was
incomplete.
Update the RT3070 register initialization to be similar to the latest Ralink
vendor driver.

With this patch my rt3070 based devices start showing a sign of life.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Align the rt2800 register initializations with the latest versions of the
Ralink vendor driver.
This patch is also preparation for the addition of support for RT3070 /
RT3071 / RT3090 / RT3390 based devices.
Signed-off-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 rt2800 version constants are inconsistent, and the version number don't
mean a lot of things anyway. Refactor the constants to have some more
meaningful names, and introduce and use some new helpers to check these
chipset revisions. At the same time rename to revision, as they are more
revision numbers rather than version numbers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Only include definitions for RT chipsets that are also used inside the
Ralink vendor drivers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Definitions taken from the latest rt2860 / rt2870 / rt3070 / rt3090 Ralink
vendor drivers.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It seems that the distinction between RF channel switch method is solely based
on the RF chipset that is used.
Refactor the channel switch decision to just take the RF chipset into account,
thereby greatly simplifying the check.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2872 needs the same rf register setup as rt3070 and rt3090, hence
use rt2800_config_channel_rt3x instead of rt2800_config_channel_rt2x.
This change allows me to actually switch channels and hence scan all
configured channels on the RT305x SoC platform (which uses a rt2872)
here.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Tested-by: NLuis Correia <luis.f.correia@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that the powersave issues on rt2500usb have been tackled, powersave
can be enabled by default again.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is needed to wake up the device automatically for receiving beacons,
and is required for proper powersave handling.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>