The hostap_cs driver is programmed for exclusive rather that shared
interrupts.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-and-Tested-by: NJack Schneider <puck@dp-indexing.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use %pM instead, and also remove stray variables
declared with DECLARE_MAC_BUF.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NKalle Valo <kalle.valo@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NVivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We were treating ieee80211_regdom module parameter hints
as core hints, this means we were not letting the user help
compliance further when using the module parameter. It also
meant that users with a device with a custom regulatory
domain set (wiphy->custom_regulatory) using this module
parameter were being stuck to the original default core
static regualtory domain. We fix this by using the static
cfg80211_regdomain alpha2 as the core hint and treating the
module parameter separately.

All iwlwifi and ath5k/ath9k/ar9170 devices which world roam
set the wiphy->custom_regulatory. This change allows users
using this module parameter to have it trated as a a proper
user hint and not have it ignored.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This uses the new configuration changes indicated up by
mac80211 when all interfaces are marked idle. We need to do
a little more work as we have our own set of virtual
wiphys within ath9k.

Only when all virtual wiphys are inactive do we allow an idle
state change for a wiphy to trigger disabling the radio.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These functions are changing the power mode of the chip, but this may
have unpredictable effects, if another code are trying to set the power
mode via 'ath9k_hw_setpower' in the same time from another context.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Uninline these functions before we add functional changes to them.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Because ath9k_setpower is called from various contexts, we have to
protect it against concurrent calls.

Changes-licensed-under: ISC
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
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>

Update tx BA window and complete the frame as failed
one if we can't clone the holding descriptor due to
unavailability of descriptors.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

oops, this one should be part of the original patch
"ath9k: downgrade assert in ath_clone_txbuf()"
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The hardware doesn't generate interrupts in some cases and so work
around this by monitoring the TX status periodically and reset the
chip if required.

This behavior of the hardware not generating the TX interrupts can
be noticed through ath9k debugfs interrupt statistics when heavy
traffic is being sent from STA to AP. One can easily see this behavior
when the STA is transmitting at a higher rates. The interrupt statistics
in the debugfs interface clearly shows that only RX interrupts alone
being generated and TX being stuck.

TX should be monitored through a timer and reset the chip only when
frames are queued to the hardware but TX interrupts are not generated
for the same even after one second. Also, we shouldn't remove holding
descriptor from AC queue if it happens to be the only descriptor and
schedule TX aggregation regarless of queue depth as it improves
scheduling of AMPDUs from software to hardware queue.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Running iperf along with p2p traffic on both TX and RX side then
stop one side, then stop the other side, then start it up again,
eventually the STA gets into a mode that it can not pass data at
all.

A hardware workaround for invalid RSSI can make FIFO write pointer
to jump over read pointer, causing RX data corruption and repeated
DMA. Both TX and RX works fine when the workaround is disabled.

To replace the original hardware work around, software looks for
frames with post delimiter CRC error and mark the RSSI invalid so
that the upperlayer will not use the RSSI associated with this
frame. So disable the hardware workaround by updating the appropriate
registers.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

RSSI reported by the RX descriptor requires little manipulation.
Manipulate and report the correct RSSI to the stack. This will
fix the improper signal levels reported by iwconfig iw dev wlanX
station dump. Also the Link Quality reported seems to be varying
(falls to zero also sometimes) when iperf is run from STA to AP.

Also use the default noise floor for now as the one reported
during the caliberation seems to be wrong.

The Signal and Link Quality before this patch (taken while TX is
in progress from STA to AP)

09:59:13.285428037 Link Quality=29/70  Signal level=-81 dBm
09:59:13.410660084 Link Quality=20/70  Signal level=-90 dBm
09:59:13.586864392 Link Quality=21/70  Signal level=-89 dBm
09:59:13.710296281 Link Quality=21/70  Signal level=-89 dBm
09:59:13.821683064 Link Quality=25/70  Signal level=-85 dBm
09:59:13.933402989 Link Quality=24/70  Signal level=-86 dBm
09:59:14.045839276 Link Quality=26/70  Signal level=-84 dBm
09:59:14.193926673 Link Quality=23/70  Signal level=-87 dBm
09:59:14.306230262 Link Quality=31/70  Signal level=-79 dBm
09:59:14.419459667 Link Quality=26/70  Signal level=-84 dBm
09:59:14.530711167 Link Quality=37/70  Signal level=-73 dBm
09:59:14.642593962 Link Quality=29/70  Signal level=-81 dBm
09:59:14.754361169 Link Quality=21/70  Signal level=-89 dBm
09:59:14.866217355 Link Quality=21/70  Signal level=-89 dBm
09:59:14.976963623 Link Quality=28/70  Signal level=-82 dBm
09:59:15.089149809 Link Quality=26/70  Signal level=-84 dBm
09:59:15.205039887 Link Quality=27/70  Signal level=-83 dBm
09:59:15.316368003 Link Quality=23/70  Signal level=-87 dBm
09:59:15.427684036 Link Quality=36/70  Signal level=-74 dBm
09:59:15.539756380 Link Quality=21/70  Signal level=-89 dBm
09:59:15.650549093 Link Quality=22/70  Signal level=-88 dBm
09:59:15.761171672 Link Quality=32/70  Signal level=-78 dBm
09:59:15.872793750 Link Quality=23/70  Signal level=-87 dBm
09:59:15.984421694 Link Quality=22/70  Signal level=-88 dBm
09:59:16.097315093 Link Quality=21/70  Signal level=-89 dBm

The link quality and signal level after this patch (take while
TX is in progress from STA to AP)

17:21:25.627848091 Link Quality=65/70  Signal level=-45 dBm
17:21:25.762805607 Link Quality=65/70  Signal level=-45 dBm
17:21:25.875521888 Link Quality=66/70  Signal level=-44 dBm
17:21:25.987468448 Link Quality=66/70  Signal level=-44 dBm
17:21:26.100628151 Link Quality=66/70  Signal level=-44 dBm
17:21:26.213129671 Link Quality=66/70  Signal level=-44 dBm
17:21:26.324923070 Link Quality=65/70  Signal level=-45 dBm
17:21:26.436831357 Link Quality=65/70  Signal level=-45 dBm
17:21:26.610356973 Link Quality=65/70  Signal level=-45 dBm
17:21:26.723340047 Link Quality=65/70  Signal level=-45 dBm
17:21:26.835715293 Link Quality=64/70  Signal level=-46 dBm
17:21:26.949542748 Link Quality=64/70  Signal level=-46 dBm
17:21:27.062261613 Link Quality=65/70  Signal level=-45 dBm
17:21:27.174511563 Link Quality=64/70  Signal level=-46 dBm
17:21:27.287616232 Link Quality=64/70  Signal level=-46 dBm
17:21:27.400598119 Link Quality=64/70  Signal level=-46 dBm
17:21:27.511381404 Link Quality=64/70  Signal level=-46 dBm
17:21:27.624530421 Link Quality=65/70  Signal level=-45 dBm
17:21:27.737807109 Link Quality=64/70  Signal level=-46 dBm
17:21:27.850861352 Link Quality=65/70  Signal level=-45 dBm
17:21:27.963369436 Link Quality=64/70  Signal level=-46 dBm
17:21:28.076582289 Link Quality=64/70  Signal level=-46 dBm
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Move its only member (u8 per) to struct ath_rate_priv.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Get rid of rssi reduce interval.
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>

ath9k rate control is based on only PER (packet error rate),
remove unused code which was intented to do rssi based rate
selection.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

After the cleanup we just use get_rate as a wrapper, skip
the wrapper.

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All current rate control algorithms agree to send management and no-ack
frames at the lowest rate. They also agree to do this when sta
and the private rate control data is NULL. We add a hlper to mac80211
for this and simplify the rate control algorithm code.

Developers wishing to make enhancements to rate control algorithms
are for broadcast/multicast can opt to not use this in their
gate_rate() mac80211 callback.

Cc: Zhu Yi <yi.zhu@intel.com>
Acked-by: NReinette Chatre <reinette.chatre@intel.com>
Cc: ipw3945-devel@lists.sourceforge.net
Cc: Gabor Juhos <juhosg@openwrt.org>
Acked-by: NFelix Fietkau <nbd@openwrt.org>
Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl-agn-rs.c already uses this.

Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Cc: ipw3945-devel@lists.sourceforge.net
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: Felix Fietkau <nbd@openwrt.org>
Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We check for this condition early on in our mac80211 get_rate()
callback ath_get_rate(), so remove this check later down the path.

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The purpose is to find the highest rate we can use.

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There are a lot of gaps here.

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This saves us 2733 bytes.

   text    data     bss     dec     hex filename
 252265    3628    1584  257477   3edc5 ath9k-has-b-rate.ko
 249905    3628    1584  255117   3e48d ath9k.ko

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Siged-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

What this does is get us our next lower rate so call it that,
ath_rc_get_lower_rix().

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is just calling another helper, so just use the other
helper directly. This should make it clear that when do not
find the next rate we stick to the current one.

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is not used, remove this.

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This is not used, and when we need to get the lowest rate
we should simply use mac80211's own rate_lowest_index(sband, sta).

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This has no functional change and just cleans up the code
to be more legible and removes a useless variable for
Multi Rate Retry.

For regular frames we use 2 retries for MRR segments [0-2].
For the last MRR segment [3] we use 4.

MRR[0] = 2
MRR[1] = 2
MRR[2] = 2
MRR[3] = 4

Cc: Derek Smithies <derek@indranet.co.nz>
Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This removes the work around implemented for transmitting on
an unsupported band on iwlwifi. This was added via the patch:

8e1856e82cb8f541e925738bebfbc473420cda68:
iwlwifi: fix rs_get_rate WARN_ON()

Cc: Mohamed Abbas <mohamed.abbas@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The case where no vaid rate is found should not happen now
but to help debugging and downgrade this to a warn.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When we're associated we should be able to send data to
target sta. If we cannot we may be trying to use the incorrect
band to talk to the sta. Lets catch any such cases, warn, and
drop the frames to not invalidate assumptions being made on
rate control algorithms when they have a valid sta to
communicate with. Any such cases should be handled and fixed.
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add omitted mutex_unlock to one of wl12xx_op_start fail paths (when
wl12xx_chip_wakeup fails).

[v2]
Power off the device, because:
\= cite from http://marc.info/?l=linux-kernel&m=124755028209880&w=2
If the chip cannot be booted, why should it remain powered on?
In some rare cases, the chip might fail to initialize, but can
recover if powered off and on again, so turning it off at this
point is the right thing to do. =/
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwl_dump_nic_error_log can be static and iwl_dump_nic_event_log
doesn't need to be exported.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Adding more detailed info about Asus motherboards and Ralink devices.
Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: NGábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

New device supported by the zd1211rw driver reported to linux-wireless.
Device string from lsusb:
"ID 083a:e501 Accton Technology Corp. ZD1211B"

RF type from dmesg:
zd1211b chip 083a:e501 v4810 high 00-1a-2a AL2230_RF pa0 g--NS
Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net>
Tested-by: Adrián Cereto<ssorgatem@esdebian.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The work that we cancel there requires the cfg80211_mutex,
so we can't cancel it under the mutex, which is fine, we
can just move it to after the locked section.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>