Previously the software scan callback was used to indicate to the hardware,
when it was safe to calibrate. This didn't really work properly, because it
depends on a specific order of software scan callbacks vs. channel changes.
Also, software scans are not the only thing that triggers off-channel
activity, so it's better to use the newly added indication from mac80211 for
this and not use the software scan callback for anything calibration related.

This fixes at least some of the invalid noise floor readings that I've seen
in AP mode on AR9160
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Writes to the analog shift registers, which are issues by the initval
programming function, require a 100 usec delay (similar to AR9002,
but in a different register range).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When updating the PAPRD table in hardware, PAPRD itself needs to be
disabled first, otherwise the hardware can throw a data bus error,
which upsets at least some platforms.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The periodic noise floor calibration is broken on this chip family, because
it keeps triggering a software-filtered noise floor calibration, but never
reads the result before uploading the history buffer value to the hardware.

Fix this with a call to ath9k_hw_getnf(), just like on AR9002.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On AR9003 the initial noise floor calibration is currently triggered
at the end of the reset without allowing the hardware to update the
baseband settings. This could potentially make scans in noisy
environments a bit more unreliable, so use the same calibration
sequence that is used on AR9002.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit f84b29ec
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue May 18 02:29:13 2010 -0700

    iwlwifi: queue user-initiated scan when doing internal scan

introduced a potential deadlock because it calls
ieee80211_scan_completed() with the priv->mutex
held, but mac80211 may call back into iwlwifi
which would lead to recursive locking. Move this
out from under the mutex.

Cc: stable@kernel.org
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix possible double priv->mutex lock introduced by commit
a69b03e9
"iwlwifi: cancel scan watchdog in iwl_bg_abort_scan" .
We can not call cancel_delayed_work_sync(&priv->scan_check) with
priv->mutex locked because workqueue function iwl_bg_scan_check()
take that lock internally.

We do not need to synchronize when canceling priv->scan_check work.
We can avoid races (sending double abort command or send no
command at all) using STATUS_SCAN_ABORT bit. Moreover
current iwl_bg_scan_check() code seems to be broken, as
we should not send abort commands when currently aborting.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
CC: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>

This makes the information available through ethtool...
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NKalle Valo <kvalo@adurom.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>

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

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NKalle Valo <kvalo@adurom.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NLennert Buytenhek <buytenh@wantstofly.org>

https://bugzilla.kernel.org/show_bug.cgi?id=16476Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Acked-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Cc: stable@kernel.org

When issuing two consecutive scans you could often end up
getting in the logs:

"ath9k: Two wiphys trying to scan at the same time"

This message is due to a race in mac80211 but addressing
that race requires some more major changes on the driver
and perhaps optimizations on mac80211 like removing the
scan complete callback alltogether. Its too late to address
this this kernel release so supress the complaint and annotate
this needs fixing for later.

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
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>

Standardize the logging macros used.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove last bits of indirect command code.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Other uses were already used direct command paths.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Powersave looks like it got broken at some point but we'll fix that up
when the command submission stuff is more understandable, which this
series helps to do.  That said, this patch should not further break
powersave.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Slightly different approach here since there are so many arguments to
the firmware command.  Just let the caller fill them in before pushing
the command to the firmware.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For now; it's a pretty easy command to hook up and whenever OLPC
figures out how they want the userspace interface to look (ie,
not iwpriv commands) we can easily add it back in.  Since the
cfg80211 conversion it wasn't working anyway.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It hasn't been hooked up to anything in a long time and it's not
even listed in any of the firmware documentation I have (and I
have v5.1, v8, v9, and v10).
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These were no longer used but were left around; Transmit Power
Control is done through the lbs_set_tpc_cfg() function.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Convert to a full direct command; previous code rolled a direct
command by hand but left the original indirect command code intact
but disabled.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Convert to a full direct command; previous code rolled a direct
command by handle but left the original indirect command code
lying around.
Signed-off-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On our hardware (050d:7050 Belkin Components F5D7050 Wireless G Adapter),
setting any WEP key with non zero index, cause rx frames corruption.

Note: perhaps (I did not check) this can be fixed differently - by using
hw_key_idx the same as true MAC key index. But according to the comment in
rt2x00mac_set_key():

"the hardware requires keys to be assigned in correct order (When key 1
is provided but key 0 is not, then the key is not found by the hardware
during RX)"

this will be quite problematic. Since WEP should not be used, disabling
hardware crypto offload for it will not hurt much. Beside static
one key WEP will still be offloaded.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Without cipher part nullify of TXRX_CSR0 register we can receive
corrupted frames (removed IV or IVC), after reloading rt2500usb module
with nohwcrypt=1 option, if previous some keys were configured into
the hardware.
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix rt2500usb hardware encryption broken by commit
96b61baf
"rt2x00: Clean up USB vendor request buffer functions"
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

base index is not used anymore and so remove it.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser
than MCS15 rate. This incorrect rate may affect switching to higher
rates as the rate control algorithm always finds MCS15 is better
than MCS15 ShortGI and results in lower throughput. Fix this by
feeding the correct user ratekbs for MCS15 ShortGI rate.

This issue affects 3 stream case very badly as the 3 stream rates are
not used at all once we scale down to MCS15 from 3 stream rates.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch adds 3 stream rate control support for AR938X family
chipsets which supports 3 streams.
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>