These warnings are exposed by gcc 4.6.
net/mac80211/sta_info.c: In function 'sta_info_cleanup_expire_buffered':
net/mac80211/sta_info.c:590:32: warning: variable 'sdata' set but not used
net/mac80211/ibss.c: In function 'ieee80211_rx_mgmt_auth_ibss':
net/mac80211/ibss.c:43:34: warning: variable 'status_code' set but not used
net/mac80211/work.c: In function 'ieee80211_send_assoc':
net/mac80211/work.c:203:9: warning: variable 'len' set but not used
net/mac80211/tx.c: In function '__ieee80211_parse_tx_radiotap':
net/mac80211/tx.c:1039:35: warning: variable 'sband' set but not used
net/mac80211/mesh.c: In function 'ieee80211_mesh_rx_queued_mgmt':
net/mac80211/mesh.c:616:28: warning: variable 'ifmsh' set but not used
 ...
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The release timer has to expire "just" after a
frame is up for release. Currently, if the timer
callback starts on time, the "!time_after" check
above will start a new timer instead of
releasing the frames.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Using the ieee80211_sta_block allows the PS code
to handle awake->doze->awake transitions of our
clients in a race-free manner.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"For best CPU usage and power consumption, having as few
frames as possible percolate through the stack is
desirable. Hence, the hardware should filter as much
as possible."

Note: Not all firmwares include the multicast filter
feature and the stack does not filter them either.
The ARP filter on the other hand was dropped from the
patch since it does not work correctly:

Quote from: Max Filippov <jcmvbkbc@gmail.com>
<http://www.spinics.net/lists/linux-wireless/msg67466.html>
"In the ARP case, when there's no other traffic on p54spi,
all ARP requests are dropped. But if there's some egress
traffic from p54spi, filter seems to work correctly:
only ARP requests that match filter pass through.

In the multicast case filter seems to work correctly, but
it treats broadcast as subject to that filtering too. By
default only 01:00:5e:00:00:01 gets into priv->mc_maclist,
so we miss all broadcasts.

These two filters seem to interfere:
- if we set ARP filter and multicast filter without bc
	=>  we miss all ARPs if there's no egress traffic;
- if we set ARP filter and multicast filter with bc or
	don't set mc filter at all => we get all ARPs.

This effect does not depend on filter setup order."
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Tested-by: NMax Filippov <jcmvbkbc@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My 14e4:4315 is SSB_IDLOW_SSBREV_26:
read32 0xfaafcff8 -> 0x600422d5
My 14e4:4328 is SSB_IDLOW_SSBREV_24:
read32 0xfaafcff8 -> 0x400422c5
My 14e4:432b is SSB_IDLOW_SSBREV_26 again:
read32 0xfaafcff8 -> 0x600422d5

For all of them wl driver is using 0x2 reject bit:
write32(0xf98) <- 0x00010002
So it seems SSB 2.3 is the exception using another bit.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ssb_chipco_set_clockmode may want to touch CC registers to control power of the
bus. However touching registers without powered_up set causes warnings.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The xpaBiasLvlFreq parameter array is made up of 16 bit words which
aren't byte-swapped like the other 16-bit eeprom parameters are.
It's only used by the AR9160.
Signed-off-by: NAdrian Chadd <adrian@freebsd.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Requesting beacon sync up to configure beacon timers properly
in hw, has be done after doing beacon config with default values.
Setting the flags in beacon config is causing the device to not
enter into network sleep on idle state.
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On AR9003 chips, doing three IQ calibrations will possibly cause chip
in stuck state. In noisy environment, chip could receive
a packet during the middle of three calibrations and it causes
the conflict of HW access and the eventual failure. It also
causes IQ calibration outliers which results in poor Tx EVM.

The IQ Cal procedure is after resetting the chip, run IQ cal 3 times
per each cal cycle and find the two closest readings and average of two.
The advantage of running Tx IQ cal more than once is that we can compare
calibration results for the same gain setting over multiple iterations.
Most of the cases the IQ failures were observed after first pass.

For the AR9485 and later chips, Tx IQ Calibration is performed along
with AGC cal. But for pre-AR9485 chips, Tx IQ cal HW has to be separated
from the rest of calibration HW to avoid chip hang. After all
calibrations are done in HW, we can start SW post-processing.
By doing this way, we minimize the SW difference among all chips.

The order of calibration (run IQ cal before other calibration) is also
needed to avoid chip hang for chips before AR9485. This issue was
originally observed with AR9382.

During the issue kernel log was filled with following message
ath: timeout (100000 us) on reg 0xa640: 0x00000001 & 0x00000001 != 0x00000000
ath: timeout (100000 us) on reg 0xa2c4: 0x00158dd9 & 0x00000001 != 0x00000000
ath: Unable to reset channel (2412 MHz), reset status -5
ath: Unable to set channel
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This helped the developers to fix an issue of chip not entering network
sleep during idle state, previously this was only available as a debug
message
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

newer chipsets support auto sleep feature, so remove the
unlikely check which does not seems to help anything
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We should protect hw_pll handler with power save wrappers and
also modularize hw_pll handler properly for better readability.

Also add a debug message to track chip resets on pll hang condition.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There is no reason why pll work handler should be part of xmit
file. move it to main.c so that reading hw check routines are
all in the same place.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We need not wake up the chip even before mutex lock is acquired and also
that it is required only if we are going to drain the txq. So place the
wrappers accordingly and this change is also useful when there are no
pending frames in the txq as we do not wake up the chip unnecessarily.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

we should program the AR9485 baseband PLL phase shift to 6 and
a redundant setting overwrites the correct value. Remove the
incorrect and unwnated register setting.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The LED gpio is incorrectly programmed for AR9300 and so the led
is not working propelry. AR93xx uses gpio 10 for LED and not the
default.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently mac80211 uses ieee80211_disable_40mhz_24ghz module
parameter to allow disabling 40MHz operation in the 2.4GHz band.
Move this handling from mac80211 to cfg80211 so that the feature
will be more generic.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NBing Zhao <bzhao@marvell.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Hw next tigger time is configured as current_tsf + (timer_period * 10) which
is wrong, it should be current_tsf + timer_period. The wrong hw timer configuration
would cause btcoex related issues.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently, the code to tear down BA sessions will
execute after queues are stopped, but attempt to
send frames, so those frames will just get queued,
which isn't intended. Move this code to before to
tear down the sessions properly.

Additionally, after stopping queues, flush the TX
queues in the driver driver to make sure all the
frames went out.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Tell the firmware to enable the life time expiry of tx packets
in the hardware. The hardware will now refer to the timestamp
in every tx packet and decide whether the packet needs to be
dropped or transmitted.
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since queues are not stopped anymore, management frames would be
dropped if the corresponding tx queue is full.
This can cause issues say when we want to setup an ampdu stream and
action frames i.e addba requests keep getting dropped frequently.
Fix this by reserving some buffers to allow management frames to
go through in queue full conditions.
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Timestamp tx packets using a HW micro-second timer.
This timestamp will be compared to the current timestamp
in the hardware and if the difference is greater than 500ms,
the packet will be dropped.
Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is in preparation to support life time expiry of packets in the
hardware to avoid head-of-line blocking where a slow client can
hog a tx queue and affect the traffic to a faster client from the same
queue. Time stamp the packets in driver to allow dropping them in the
hardware if they are queued for more than 500ms.

If queues are stopped, packets will be queued up outside the driver.
Since we will be able to timestamp the packets only after they hit the
driver, the timestamp will be less accurate since we cannot consider
the time the packets spent in queues outside the driver. With this commit,
to achieve accurate timestamping, the tx queues will not be stopped in
normal conditions. The only scenarios where the queues will be stopped are
when firmware commands are executing or if the interface is brought down.
Now, we need to be prepared for a situation where packets hit the driver
even after the tx queues are full. Drop all such packets in the driver itself.
Signed-off-by: NPradeep Nemavat <pnemavat@marvell.com>
Signed-off-by: NNishant Sarmukadam <nishants@marvell.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

My commit 3598e177
"iwlwifi: fix enqueue hcmd race conditions" move hcmd callback after
command queue reclaim, to avoid call it with hcmd_lock. But since
queue read index was updated, cmd data can be overwritten. Fix problem
by calling callback before taking hcmd_lock and queue reclaim.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We probably got false positive results for checking PLL being down.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

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

Set the maximum ampdu size of a station correctly
in the target by using the ampdu_factor.
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Register the driver's maximum ampdu subframe limit to mac80211.
* Cleanup the target capabilities structure and fix an endian issue.
* Fix BTCOEX by sending a command to the target when the BT priority
  changes.
* Bump the required firmware version to 1.1
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

Default min_msk on my 0x4312 is 0x80000CBB, not 0xCBB. Now we follow
specs and wl (noticed in MMIO dumps).
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR9340 is a AR9003 family built-in 2x2 wmac of ar934x SOCs. It is single band
in ar9341 SOC and dual band in ar9344/ar9342 SOCs.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>