Multiple devices use almost the same .cfg with minor differences.
Use macro and remove the duplication. By doing this, reduce
the chance for mistake while modify .cfg parameters
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

For debugging purpose, keep track of the bt coex enable/disable state.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

For WiFi/WiMAX combo devices, if WiMAX own the RF, WiFi driver
try to access RF and fail. This is the W/A to To avoid WiFi keep
reloading firmware and try to access RF again.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

For enhanced tx power table in EEPROM, add more detail logging
to help debugging
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

For logging EEPROM related info, instead of using IWL_DEBUG_INFO,
use the dedicated logging (IWL_DEBUG_EEPROM) for easier debugging
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Adding new debug type to log EEPROM related data
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This removes the old TX power reading code, it isn't
necessary since the new code is able to read all the
various EEPROM layouts due to relying on information
contained in the EEPROM.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

The current EEPROM reading code has some layout
assumptions that now turned out to be false with
some newer versions of the EEPROM. Luckily, we
can avoid all such assumptions by using data in
the EEPROM itself, so implement using that.

However, for risk mitigation purposes, keep the
old reading code for current hardware for now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Some fields we didn't previously use from the
enhanced TX power structure will be needed in
the next patch, so rename them to their correct
names to be able to use them and change code
reading them accordingly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

For the new 1x1 devices, hw and uCode will support rx
antenna diversity, but we need to indicate 1x1 device to
AccessPoint to make sure it won't use MIMO.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

The compiler correctly warns:
iwl-agn-tx.c: In function ‘iwlagn_tx_status_reply_compressed_ba’:
iwl-agn-tx.c:1240: warning: ‘bitmap’ may be used uninitialized in this function

Move the debug print to the branch that reads the
bitmap, and move the variables too so it's more
obvious where they are needed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

In function iwlagn_bss_info_changed(), we need to check if the driver
is ready before doing real work. Also, the previously put WARN() is
removed because the vif is not guaranteed to be valid. uCode restart
routine will clear the vif.
Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

This prevent bad fixed_rate keeps crashing uCode in an endless loop.
Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

For both 6005 and 6030 devices, change the led compensation to 57
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>

Commit 6175ddf0 changes the way
memcpy_toio() works for x86_64, causing firmware loading to fail for
some Ralink WLAN devices with the rt2800pci driver since linux 2.6.34.
This causes the log message: "phy0 -> rt2800pci_load_firmware: Error -
PBF system register not ready.".

Fix this by using __iowrite32_copy instead of memcpy_toio().
Signed-off-by: Wolfgang Kufner <wolfgang.kufner@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Wolfgang Kufner <wolfgang.kufner@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The stray semicolon after DEBUG_PRINTK_MSG causes things
like "if (...) WARNING(...); else {}" to fail with syntax error.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The Queue names were incorrectly copied from the legacy drivers,
as a result the queue names were inversed to what was expected.

This renames the queues using this mapping:
	QID_AC_BK -> QID_AC_VO (priority 0)
	QID_AC_BE -> QID_AC_VI (priority 1)
	QID_AC_VI -> QID_AC_BE (priority 2)
	QID_AC_VO -> QID_AC_BK (priority 3)

Note that this was a naming problem only, which didn't affect
the assignment of frames to their respective queues.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add a queue entry flag ENTRY_DATA_STATUS_PENDING,
which can be used to indicate a queue entry has
returned from the hardware and is waiting for
status processing. Using this flag we can add
some extra sanity checks to prevent queue corruption.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add the rt2x00_dmastart function to rt2x00lib which
marks the queue_entry as "owned by device", and increased
the Q_INDEX number.

This cleanups up the index handling by rt2x00lib which
at until so far used hackish approaches to keep the
RX queue index numbering sane.

The rt2x00pci.c changes are from Helmut Schaa
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add a new command to the queue handlers: "flush",
this moves the flush() callback from mac80211
into rt2x00queue and adds support for flushing
the RX queue as well.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add wrapper functions in rt2x00queue.c to
start & stop queues. This control must be protected
using a mutex.

Queues can also be paused which will halt the flow
of packets between the driver and mac80211. This doesn't
require a mutex protection.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

As part of the queue refactoring, change the queue callback
function names to have 3 different actions: start, kick & stop.

We can now also remove the STATE_RADIO_RX_ON/STATE_RADIO_RX_OFF
device_state flags, and replace the usage with using the
start_queue/stop_queue callback functions.
This streamlines the RX queue handling to the
similar approach as all other queues.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

As part of the queue refactoring, we now introduce
3 queue commands: start, kick, stop.

 - Start: will enable a queue, for TX this will
   not mean anything, while for beacons and RX
   this will update the registers to enable the queue.
 - Kick: This will kick all pending frames to
   the hardware. This is needed for the TX queue
   to push all frames to the HW after the queue
   has been started
 - Stop: This will stop the queue in the hardware,
   and cancel any pending work (So this doesn't
   mean the queue is empty after a stop!).

Move all code from the drivers into the appropriate
functions, and link those calls to the old rt2x00lib
callback functions (we will fix this later when we
refactor the queue control inside rt2x00lib).
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Commit 02044643 "Check for specific changed
flags when updating the erp config" changed the way in which a new beacon
interval gets handled. However, due to a bug in rt2800usb and rt2800pci the
beacon interval was reset during each scan, thus causing problems in AdHoc
mode.

Fix this by not cleaning up the beacon interval when killing the beacon queue
but just prevent the device from sending out beacons.
Reported-by: Wolfgang Kufner <wolfgang.kufner@gmail.com>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Recent changes to the TX-done code of rt2x00 resulted in TX-ed frames not
being returned to mac80211 in the original state, and therefore with
insufficient headroom for re-transmissions.

Fix this by reverting the changes done and by ensuring we remove the inserted
L2pad by moving the header backwards instead of the data forwards.

At the same time also make sure that the rt2x00queue_remove_l2pad will not
move any memory when a frame has no data at all.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Jay Hung <Jay_Hung@ralinktech.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When an rt2x00 USB device is unplugged while in use, it reliably
hangs the whole system.  After some time the watchdog prints:

BUG: soft lockup - CPU#0 stuck for 64s! [kworker/u:0:5]
...
[<c01a88d8>] (usb_submit_urb+0x0/0x2ac) from [<bf0e752c>] (rt2x00usb_kick_rx_entry+0xb4/0xe8 [rt2x00usb])
[<bf0e7478>] (rt2x00usb_kick_rx_entry+0x0/0xe8 [rt2x00usb]) from [<bf0e7588>] (rt2x00usb_clear_entry+x28/0x2c [rt2x00usb])
[<bf0e7560>] (rt2x00usb_clear_entry+0x0/0x2c [rt2x00usb]) from [<bf0d5bc4>] (rt2x00lib_rxdone+0x2e0/0x2f8 [rt2x00lib])
[<bf0d58e4>] (rt2x00lib_rxdone+0x0/0x2f8 [rt2x00lib]) from [<bf0e7e00>] (rt2x00usb_work_rxdone+0x54/0x74 [rt2x00usb])
[<bf0e7dac>] (rt2x00usb_work_rxdone+0x0/0x74 [rt2x00usb]) from [<c00542b4>] (process_one_work+0x20c/0x35c)

Clear the DEVICE_STATE_PRESENT flag when usb_submit_urb()
returns -ENODEV to fix this.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add RF chip definition
Signed-off-by: RA-Jay Hung <jay_hung@ralinktech.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John 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: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Add and modify NIC Configuration and LED definition of EEPROM
Signed-off-by: RA-Jay Hung <jay_hung@ralinktech.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Reduces the likelihood of false pulse detects in the hardware
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The EEPROM contains scale factors for the tx power, which define
the range of allowable difference between target power and training
power. If the difference is too big, PA predistortion cannot be used.
For 2.4 GHz there is only one scale factor, for 5 GHz there are
three, depending on the specific frequency range.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The EEPROM PAPRD rate mask fields only contain mask values for actual
rates in the low 25 bits. The upper bits are reserved for tx power
scale values. Add the proper mask definitions and use them before
writing the values to the register.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

To be able to measure the thermal values correctly for PAPRD, we need
to send training frames before setting up the gain table for the measurement,
and then again afterwards for the actual training.

For further improvement, send training frames at MCS0 instead of 54 MBit/s
legacy. That way we can use the No-ACK flag for the transmission, which
speeds up PAPRD training in general, as the hardware won't have to
retransmit and wait for ACK timeout (was previously set to 4 * 6
transmission attempts).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Testing shows that adjusting the slot time based on the coverage class
produces very high latencies and very low throughput on long distance links.

Adjusting only the ACK timeout and leaving the slot time at the regular
values - while technically not optimal for CSMA - works a lot better on
long links (tested with 10 km distance)
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

(u32) -1 is not particularly useful as a slottime default, so even though
the ath9k_hw default should never get used, it's better to pick something
sane here.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>