rt2800 devices should adjust their tx power in accordance with the
eeproms temperature calibration values. Add a new driver callback
gain_calibration that is called every 4 seconds.

The rt2800 gain calibration routine simply runs the tx power
configuration that takes care of calculating the temperature
compensation delta.

We don't need to synchronize the calls to rt2800_config_txpower
as they should all happen from mac80211's single threaded workqueue.
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>

Fix the indention in rt2800_compesate_txpower and also fix a typo in
the function name rt2800_compesate_txpower -> rt2800_compensate_txpower.
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>

Previously the HT40 tx power compensation value was calculated for each
rate. However, the calculation is independent of the tx rate and as such
can be precalculated and just passed in for each rate.
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>

Move the HT40 check inside the calculation function to make it easier
for a later cleanup.
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>

When setting up multiple BSSIDs in AP mode on an rt2800pci device we
previously used the STAs AID to select an appropriate key slot. But
since the AID is per VIF we can end up with two STAs having the same AID
and thus using the same key index. This resulted in one STA overwriting
the key information of another STA.

Fix this by simply searching for the next unused entry in the pairwise
key table.

Also bring the key table init in sync with deleting keys by initializing
the key table entries to 0 instead of 1.
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>

HT and no-HT rt2x00 devices use a partly different TX descriptor.
Optimize the tx desciptor memory layout by putting the PLCP and HT
substructs into a union and introduce a new driver flag to decide which
TX desciptor format is used by the device.

This saves us the expensive PLCP calculation fOr HT devices and the HT
descriptor setup on no-HT devices.
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
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 special case shouldn't happen very often. Only if a frame that
is not intended to be aggregated ends up in an AMPDU _and_ was intended
to be sent at a different MCS rate as the aggregate. Hence, using
unlikely is justified.
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>

In some cases (tx path for example) we don't need to check for non-tx
queues in rt2x00queue_get_queue. Hence, introduce a new method
rt2x00queue_get_tx_queue that is only valid for tx queues and use it in
places where only tx queues are valid.

Furthermore, this new method is quite short and as such can be inlined
to avoid the function call overhead.

This only converts the txdone functions of drivers that don't use an ATIM
queue and the generic tx path.
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 rt2800 specific code contains a lots of whitespace damage caused by
the commit 'rt2x00: Add support for RT5390 chip'.

This patch fixes those whitespace errors.
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
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>

Add new RT5390 chip support
Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Revise/Add GPIO register related definitions
Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Make the definition of protection related registers more precisely
Signed-off-by: NShiang Tu <shiang_tu@ralinktech.com>
Acked-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>

TX_PWR_CFG_* setting need to consider below cases
-compesate 20M/40M tx power delta for 2.4/5GHZ band
-limit maximum EIRP tx power to power_level of
 regulatory requirement
Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For RT3070/RT3090/RT3390 with RX antenna diversity support, we must select
default antenna using gpio control way even if we do not turn on
antenna diversity feature.

Seperate the meaning of TX/RX chain and antenna. Some chips use
2x2 TX/RX chain but may have 3 RX antennas or 1x1 TX/RX chain
but may have 2 RX antennas to do antenna diversity.
Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit 739fd940 ("rt2x00: Pad beacon to multiple of 32 bits")
added calls to skb_pad() without checking the return value,
which could cause problems if any of those calls does happen
to fail. Add checks to prevent this from happening.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use the specific mac field of the wcid_entry structure to copy the MAC
address to, instead of just overwriting the structure.
Previous code resulted in the same, but this form is cleaner.
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>

CLOCK CYCLE: Clock cycle count in 1us
PCI:0x21, PCIE:0x7d, USB:0x1e
Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.com>
Acked-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 allows to dynamically remove beaconing interfaces without
shutting beaconing down on all interfaces.

The only place to start and stop beaconing are now the start- and
stop_queue callbacks. Hence, we can remove some register writes during
interface bring up (config_intf) and only write the correct sync mode
to the register there.

When multiple beaconing interfaces are present we should enable
beaconing as soon as mac80211 enables beaconing on at least one of
them. The beacon queue gets stopped when the last beaconing
interface was stopped by mac80211. Therefore, introduce another
interface counter to keep track ot the number of enabled beaconing
interfaces and start or stop the beacon queue accordingly.

To allow single interfaces to stop beaconing, add a new driver
callback clear_beacon to clear a single interface's beacon without
affecting the other interfaces. Don't overload the clear_entry callback
for clearing beacons as that would introduce additional overhead
(check for each TX queue) into the clear_entry callback which is used
on the drivers TX/RX hotpaths.

Furthermore, the write beacon callback doesn't need to enable beaconing
anymore but since beaconing should be disabled while a new beacon is
written or cleared we still disable beacon generation and enable it
afterwards again in the driver specific callbacks. However, beacon
related interrupts should not be disabled/enabled here, that's solely
done from the start- and stop queue callbacks. It would be nice to stop
the beacon queue just before the beacon update and enable it afterwards
in rt2x00queue itself instead of the current implementation that relies
on the driver doing the right thing. However, since start- and
stop_queue are mutex protected we cannot use them for atomic beacon
updates.
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>

The aggregation code currently doesn't implement the
buffer size negotiation. It will always request a max
buffer size (which is fine, if a little pointless, as
the mac80211 code doesn't know and might just use 0
instead), but if the peer requests a smaller size it
isn't possible to honour this request.

In order to fix this, look at the buffer size in the
addBA response frame, keep track of it and pass it to
the driver in the ampdu_action callback when called
with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
way the driver can limit the number of subframes in
aggregates appropriately.

Note that this doesn't fix any drivers apart from the
addition of the new argument -- they all need to be
updated separately to use this variable!
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Basically fix and fine-tune RT3070/RT3071/RT3090 chip RF initial value
when call rt2800_init_rfcsr
Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.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>

PCI/PCIE radio off behavior is different from SOC/USB.
They mainly use MCU command to disable DMA, TX/RX and enter power saving mode.
Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Pad beacon to a multiple of 32 bits in preparation for the change
from memcpy_toio() to __iowrite32_copy() in register_multiwrite().
Signed-off-by: NWolfgang Kufner <wolfgang.kufner@gmail.com>
Acked-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>

Implement the get_survey callback to allow user space to read statistics
about the current channel condition.
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>

Add and modify NIC Configuration and LED definition of EEPROM
Signed-off-by: NRA-Jay Hung <jay_hung@ralinktech.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>

Using static const generally increases object text and decreases data size.
It also generally decreases overall object size.

   text	   data	    bss	    dec	    hex	filename
  40197	     56	   8336	  48589	   bdcd	drivers/net/wireless/rt2x00/rt2800lib.o.new
  40205	     56	   8336	  48597	   bdd5	drivers/net/wireless/rt2x00/rt2800lib.o.old
Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Modified from Eddy's patch by adding the RT3370 USB support as well.
Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Cc: Eddy Tsai <Eddy_Tsai@ralinktech.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt2800lib.c:831: ERROR: inline keyword should sit between storage class and type
Signed-off-by: NMark Einon <mark.einon@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The BSSID register shouldn't be set in AP mode on some older devices (like
rt73usb) as it breaks hw crypto on these. However, rt2800 devices explicitly
need the BSSID register set to the same value as our own MAC address (only
in AP mode).

Hence, don't set the BSSID from rt2x00lib but move it down into rt2800 to
avoid problems on older devices.

This fixes a regression (at least for rt73usb) and avoids a new regression
for rt2800 devices in 2.6.36.
Reported-by: NJohannes Stezenbach <js@sig21.net>
Reported-by: NLee <lee-in-berlin@web.de>
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 tx descriptor values qid, cw_min, cw_max and aifs are directly
accessible through the tx entry struct. So there's no need to copy
them into the tx descriptor and passing them to the indiviual drivers.
Instead we can just get the correct value from the tx entry.
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>

At least some devices need such a long time to inititalize WPDMA. This
only increases the maximum wait time and shouldn't affect devices that
have been working before.
Reported-by: NJoshua Smith <jesmith@kaon.com>
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>

All rt2x00 devices used the same Tx and Rx ring size (24 entries) till
now. Newer devices (like rt2800) can however make use of a larger TX and
RX ring due to 11n capabilities (AMPDUs of size 64 for example).

Hence, bring rt2x00 in sync with the legacy drivers and use the same TX
and RX ring sizes. Also remove the global defines RX_ENTRIES, TX_ENTRIES,
BEACON_ENTRIES and ATIM_ENTRIES and use per driver values.

That is 24 entries for rt2400pci, 32 entries for rt2500pci, rt2500usb,
rt61pci and rt73usb and 128 (RX) and 64 (TX) for rt2800pci and rt2800usb.
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>

Remove the magic value initialisation of the TXOP_CTRL_CFG register by
defining its fields and using them during intialisation. The field
RESERVED_TRUN_EN is referred to as reserved, however it is set to 1 by
the legacy drivers. Hence, do the same.
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>

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>

If a frame is not meant to be sent as AMPDU or part of it the hw might
still decide to aggregate this frame if a previous frame started an
AMPDU. However, this will limit the usefulness of the reported tx rate
since the reported rate will be the one specified in the TXWI of the
first frame and thus it is not possible to reliably caculate the
number of retrys by substracting the reported tx rate from the tx rate
in the TXWI.

To fix this issue, only report the successful rate for frames that were
not meant to be aggregated but ended up in an aggregate.

Example:
Frame A (MCS7, AMPDU=1) B (MCS7, AMPDU=1) C (MCS12, AMDPU=0, PROBE_RATE)

Although frame C shoudn't be aggregated the hw might sill put it
into an AMPDU together with A and B. If the transmission succeeds the tx
status will contain MCS7 for all three frames. In that case we should
only report MCS7 as success rate and avoid reporting MCS12-MCS8 as
failed tx attempts as this will affect the future rate control
decisions.

This oddity might strike us in other scenarious as well but the most
common "wrong" report happened for frames used to probe a different tx
rate.

This improves the rate control decisions notable.
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>

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 TX_STA_FIFO contains some information for identifying
a outgoing frame, however matching by WCID and ACK status is
not sufficient to 100% identify the macthing queue_entry structure
(containing the SKB buffer) which belongs to the status report.

Within TX_STA_FIFO we have a 4-bit field named PACKETID, which is
currently used to encode the queue id. The queue ID is however
limited to values from 0 to 3, which means 2 bits are sufficient
to encode the value. With the remaining 2 bits we can encode a
partial queue_entry index number. The value of PACKETID is not
allowed to become 0, with the queue ID ranging from 0 to 3, at least
one of the bits for the entry identification must be 1.

That leaves us with 3 possible values we can still encode in the
bits. Altough this doesn't allow 100% accurate matching of the
TX_STA_FIFO queue to a queue_entry structure, it at least improves
the accuracy. This allows us to better detect if we have missed the
TX_STA_FIFO report, which in turn reduces the number of watchdog
warnings regarding the TX status timeout.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

rt61pci and rt2800 devices can use up to 7 different rates per tx frame.
However, the device uses a global fallback table. Hence, the rc
algortihm cannot specify multiple rates to try but the device is able to
report multiple rates (based on the retry table). Specify that behavior
by correctly setting max_report_rates and max_rates.

This makes rt2x00 and minstrel play nicer together.
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>

Since rt2x00 USB devices have no chance to know when a beacon was sent
out in AP mode currently all broad- and multicast traffic is buffered in
mac80211 but never sent out at all.

Unfortunately we have no chance in sending the traffic out after a
DTIM beacon due to hw limitations. Hence, instead of never sending the
buffered traffic out better send it out immediately.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Reported-by: NLauri Hintsala <lauri.hintsala@bluegiga.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since HT protection is now configurable via mac80211 we don't need this
special case for PCI devices anymore. The HT protection config will be
overwritten as soon as mac80211 sends us a HT operation mode. Hence,
bring the HT MM40 protection config in sync with the other HT protection
registers and initialize it to no protection.
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>

Update the HT operation mode when mac80211 sends it to us and set
the different HT protection modes and rates accordingly. For now
only use CTS-to-self with OFDM 24M or CCK 11M when protection is
required.
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>