If its WiFi/BT combo device, the statistics notification sent by
uCode will include the additional BT related statistics counters.

Adding new data structure to support the new layout.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

drivers/net/wireless/b43/phy_n.c:512:53: warning: cast truncates bits from constant value (ffff0fff becomes fff)
drivers/net/wireless/b43/phy_n.c:765:66: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/b43/phy_n.c:1012:38: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/phy_n.c:1119:38: warning: cast truncates bits from constant value (ffff0fff becomes fff)
drivers/net/wireless/b43/phy_n.c:2458:56: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
drivers/net/wireless/b43/phy_n.c:2933:38: warning: cast truncates bits from constant value (ffff0fff becomes fff)
drivers/net/wireless/b43/phy_n.c:3294:57: warning: cast truncates bits from constant value (ffff3fff becomes 3fff)
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

  CHECK   drivers/net/wireless/b43/main.c
drivers/net/wireless/b43/main.c:111:5: warning: symbol 'b43_modparam_pio' was not declared. Should it be static?
  CHECK   drivers/net/wireless/b43/phy_g.c
drivers/net/wireless/b43/phy_g.c:975:56: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
  CHECK   drivers/net/wireless/b43/phy_lp.c
drivers/net/wireless/b43/phy_lp.c:2701:6: warning: symbol 'b43_lpphy_op_switch_analog' was not declared. Should it be static?
drivers/net/wireless/b43/phy_lp.c:1148:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1525:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1529:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
  CHECK   drivers/net/wireless/b43/wa.c
drivers/net/wireless/b43/wa.c:385:60: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:403:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:405:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:415:71: warning: cast truncates bits from constant value (ffff0fff becomes fff)

AFAICT, none of these amount to real bugs.  But this reduces warning
spam from sparse w/o significantly affecting readability of the code (IMHO).
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The existing code seemed to be somewhat based on the datasheet, but
varied substantially from the vendor-provided driver.  This mirrors the
handling of the rtl8185 case from that driver, but still neglects the
specifics for the rtl8180 hardware.  Those details are a bit muddled...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21:    expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21:    got int
drivers/net/wireless/mwl8k.c:1575:42:    expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42:    got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50:    expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50:    got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50:    expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50:    got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27:    expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27:    got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20:    expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20:    got unsigned short [unsigned] [usertype] cap

At least the last one looks like a real bug...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NLennert Buytenhek <buytenh@wantstofly.org>

  CHECK   drivers/net/wireless/rt2x00/rt2x00debug.c
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28:    expected restricted __le32 [usertype] chip_rev
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28:    got restricted __le16 [usertype] <noident>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>

  CHECK   drivers/net/wireless/ipw2x00/libipw_module.c
drivers/net/wireless/ipw2x00/libipw_module.c:65:21: warning: symbol 'libipw_config_ops' was not declared. Should it be static?
drivers/net/wireless/ipw2x00/libipw_module.c:66:6: warning: symbol 'libipw_wiphy_privid' was not declared. Should it be static?
  CHECK   drivers/net/wireless/ipw2x00/libipw_wx.c
drivers/net/wireless/ipw2x00/libipw_wx.c:415:17: warning: symbol 'ssid' shadows an earlier one
drivers/net/wireless/ipw2x00/libipw_wx.c:324:9: originally declared here
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

  CHECK   drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2100.c:177:28: warning: symbol 'ipw2100_pm_qos_req' was not declared. Should it be static?
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/ath/ath9k/main.c:282:26: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/main.c:282:26:    expected restricted __le16 [usertype] duration_id
drivers/net/wireless/ath/ath9k/main.c:282:26:    got int
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Ever since

commit e1b3ec1a
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Mon Mar 29 12:18:34 2010 +0200

    mac80211: explicitly disable/enable QoS

mac80211 is telling drivers, in particular
iwlwifi, whether QoS is enabled or not.

However, this is only relevant for station mode,
since only then will any device send nullfunc
frames and need to know whether they should be
QoS frames or not. In other modes, there are
(currently) no frames the device is supposed to
send.

When you now consider virtual interfaces, it
becomes apparent that the current mechanism is
inadequate since it enables/disables QoS on a
global scale, where for nullfunc frames it has
to be on a per-interface scale.

Due to the above considerations, we can change
the way mac80211 advertises the QoS state to
drivers to only ever advertise it as "off" in
station mode, and make it a per-BSS setting.
Tested-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"Recover from tx stall" function is available for all devices except
4965, here add the functionality to 4965.
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Display "wait_for_silence_timeout_cnt" for _agn devices
in debugfs as part of uCode statistics
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Add wait_for_silence_timeout_cnt to statistics_dbg structure
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Smatch complains that "upriv->read_urb" gets dereferenced before
checking for NULL.  It turns out that it's possible for
"upriv->read_urb" to be NULL so I added checks around the dereferences.

Also I remove an "if (upriv->bap_buf != NULL)" check because
"kfree(NULL) is OK.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

An A-MPDU may contain several subframes each containing its own
CRC for the data. Each subframe also has a respective CRC for the
MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
ACK frames that have a valid data CRC but have failed to pass the
CRC for the MPDU length, if and only if the subframe is not the
last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
been caught. Discarding those subframes results in packet loss under
heavy stress conditions, an example being UDP video. Since the
frames are ACK'd by hardware we need to let these frames through
and process them as valid frames.

Cc: Tushit Jain <tushit.jain@atheros.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This fixes this sparse complaint:

  CHECK   drivers/net/wireless/ath/ath9k/htc_drv_main.c
drivers/net/wireless/ath/ath9k/htc_drv_main.c:441:5:
	warning: symbol 'ath9k_htc_tx_aggr_oper'
		 was not declared. Should it be static?
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.

Here is an example how this could happen (thanks Bob!):

cpu 0:                                      cpu 1:

ath5k_rx_stop
                                            ath5k_tasklet_rx
sc->rxlink = NULL;   /* just in case */
                                              // following doesn't link used
                                              // buffer to prev.
                                              ath5k_rxbuf_setup()

In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
not changed so rxlink should not be changed as well.

In ath5k_intr() we seem to  try to work around a hardware bug, as the comment
(which is copied 1:1 from the HAL) suggests. I don't see how this could help.
Also the HAL does not set rxlink in this case (So where does this code come
from? It has been there since the first import of ath5k). Changed to just
increment a statistics counter.

After this patch rxlink is only set to NULL before we initialize rx descriptors
and updated when the descriptors are linked together.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Based on a patch from Bruno Randolf, attempting useful
work while we are resetting the chip just leads to interface
lockups and bad descriptor data, and possibly DMAing to
freed buffers.  Let's suspend all tasklets while
reprogramming the registers in the card to avoid such
problems.

In the future we can convert the tasklets to threaded
interrupt handlers to simplify things.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We currently trigger a reset via a tasklet when certain error
conditions are detected so that the card will (eventually)
restart.  Unfortunately this makes locking complicated since
reset can also be called in process context (e.g. for channel
change).  Currently nothing protects against concurrent resets,
which can be the source of corruption bugs.

Reset takes too long to spinlock the whole thing, so this
patch moves deferred resets into the mac80211 workqueue to
enable use of sc->lock mutex.
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Acked-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

According to documentation, The following chip revisions were never sold:

- AR9280 v1.0
- AR9285 v1.0
- AR9285 v1.1
- AR9287 v1.0

Removing initvals specific to these chip revisions saves around 30k in
binary size (tested on MIPS).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We must call del_airo_dev() before free_netdev() since we call
add_airo_dev() exactly after alloc_netdev().
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch 'ath9k: fix a buffer leak in A-MPDU completion' addressed the
issue of running out of buffers/descriptors in the tx path if a STA is
deleted while tx status feedback is still pending.
The remaining issue is that the skbs of the buffers are not reclaimed,
leaving a memory leak.
This patch fixes this issue by running the buffers through
ath_tx_complete_buf(), ensuring that the pending frames counter is also
updated.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

num_sec_wiphy means max secondary wifis that the driver can accomudate.
So cancelling wiphy work should be based on the presence of
secondary wifis.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove tMinCalPower from ath9k_hw_set_def_power_cal_table(), as it's
never used.  Remove corresponding arguments of the functions calculating
that value.

Original patch by Prarit Bhargava <prarit@redhat.com>
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

LED should be ON when the radio is put into FULL SLEEP mode during the idle
unassociated state.
Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR5008+ and AR9003 currently use two separate implementations of the
ath9k_hw_loadnf function. There are three main differences:

 - PHY registers for AR9003 are different
 - AR9003 always uses 3 chains, earlier versions are more selective
 - The AR9003 variant contains a fix for NF load timeouts

This patch merges the two implementations into one, storing the
register array in the ath_hw struct. The fix for NF load timeouts is
not just relevant for AR9003, but also important for earlier hardware,
so it's better to just keep one common implementation.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Occasionally the hardware can send out tx status information with the wrong
TID. In that case, the BA status cannot be trusted and the aggregate
must be retransmitted.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

If the receive path gets stuck, a full hardware reset is necessary to
recover from it. If this happens during a scan, the whole scan might fail,
as each channel change bypasses the full reset sequence.
Fix this by resetting the fast channel change flag if stopping the
receive path fails.

This will reduce the number of error messages that look like this:
ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x40000020
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PDADC values were only generated for values surrounding the target
index, however not for the target index itself, leading to a minor
error in the generated curve.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On AR9285, the antenna switch configuration register uses more than just
16 bits. Because of an arbitrary mask applied to the EEPROM value that
stores this configuration, diversity was broken in some cases, leading
to a significant degradation in signal strength.
Fix this by changing the callback to return a 32 bit value and remove
the arbitrary mask.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All callback functions are gathered in rt2x00dev->ops except
for the callback functions which are used in rt2800lib to
acces rt2800pci/usb.

Move the priv pointer from rt2x00dev to rt2x00dev->ops and
rename it to drv to make it obvious that it is the driver callback
structure.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Large parts of the firmware initialization are shared
between rt2800pci and rt2800usb. Move this code into
rt2800lib.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently rt2x00 uses the TSF_SYNC_BEACON mode for all beaconing
interface types. However, TSF_SYNC_BEACON is meant for IBSS networks and
thus implements TSF merging in the hardware. Rename TSF_SYNC_BEACON to
TSF_SYNC_ADHOC to better express its purpose and introduce the missing
TSF sync mode TSF_SYNC_AP_NONE which should be used for beaconing modes
that don't need TSF merging.
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>

Activating the TBTT interrupt when a beacon interval of 0 is configured
results in an interrupt storm causing the machine to hang. Hence,
initialize the beacon interval to a reasonable default of 100TUs.
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>

Using the set_tim callback without managing the DTIM count and the
broad- and multicast buffering in hw, fw or the driver results in wrong
DTIM count values being sent out in beacons. Since all PCI drivers
fetch new beacons periodically and hence get an updated TIM we can just
remove the set_tim callback from these.

The rt2x00 USB drivers don't update the beacon periodically and thus
rely on the set_tim callback to get a correct TIM for beacon
transmission. USB devices still suffer from the DTIM count being wrong
under some circumstances but removing the set_tim callback from these
would cause more harm then good.
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>