this callback is called during suspend/resume and also via iw command.
it configures parameters like sifs, slottime, acktimeout in
ath9k_hw_init_global_settings where few REG_READ, REG_RMW are also done
and hence the need for PS wrappers

Cc: stable@kernel.org
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Due to some recent optimization done in the way the mac address
bytes are written into the OTP memory, some AR9485 chipsets were
forced to use the first byte from the eeprom template and the
remaining bytes are read from OTP.

AR9485 happens to use generic eeprom template which has 0x1 as
the first byte causes issues in bringing up the card.

So fixed the eeprom template accordingly to address the issue.

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Signed-off-by: NSenthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch addresses an issue with incorrect HW register
AR_PHY_TX_IQCAL_CORR_COEFF_B1 definition which leads to incorrect clibration.

Cc: stable@kernel.org
Signed-off-by: NAlex Hacker <hacker@epn.ru>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit ebefce3d failed
to set proper PMU value to address ripple issue for AR9485.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

CTL power data incorrect in ctlPowerData_2G field of ar9300_eeprom.
Setting incorrect CTL power in calibration is causing lower tx power.
Tx power was reported as 3dBm while operating in channel 6 HT40+/
in channel 11 HT40- due to CTL powers in the calibration is set to
zero.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

We receive many bug reports about system hang during suspend/resume
when ath9k driver is in use. Adrian Chadd remarked that this problem
happens on systems that have ASPM disabled.

To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe
downstream port device, which ath9k device is connected to, has ASPM
disabled.

Bug was introduced by:

commit 53bc7aa0
Author: Vivek Natarajan <vnatarajan@atheros.com>
Date:   Mon Apr 5 14:48:04 2010 +0530

    ath9k: Add support for newer AR9285 chipsets.

Patch should address:
https://bugzilla.kernel.org/show_bug.cgi?id=37462
https://bugzilla.kernel.org/show_bug.cgi?id=37082
https://bugzilla.redhat.com/show_bug.cgi?id=697157

however I did not receive confirmation about that, except from Camilo
Mesias, whose system stops hang regularly with this patch (but still
hangs from time to time, but this is probably some other bug).
Tested-by: NCamilo Mesias <camilo@mesias.co.uk>
Cc: stable@kernel.org # 2.6.35+
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With an uninitialized chainmask, the per-channel power will only contain
the power limits for a single chain instead of the combined tx power.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some devices (e.g. Ubiquiti AirRouter) ship with broken EEPROM chainmask
data, which breaks the initial calibration after a hardware reset.
To fix this, mask the eeprom chainmask with the chainmask of the chip,
and use the chip chainmask if the result is zero.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Cc: ath9k-devel@lists.ath9k.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/ath/ath9k/hif_usb.c +135 hif_usb_mgmt_cb(6) warn:
variable dereferenced before check 'cmd'
drivers/net/wireless/ath/ath9k/btcoex.c +77 ath9k_hw_init_btcoex_hw(38)
error: buffer overflow 'ah->hw_gen_timers.gen_timer_index' 32 <=
2009813776
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

drivers/net/wireless/ath/ath9k/init.c:199:21: warning: context imbalance
in 'ath9k_reg_rmw' - different lock contexts for basic block
drivers/net/wireless/ath/ath9k/xmit.c:1175:31: warning: context
imbalance in 'ath_drain_txq_list' - unexpected unlock
drivers/net/wireless/ath/ath9k/xmit.c:2047:23: warning: context
imbalance in 'ath_tx_process_buffer' - unexpected unlock
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c:3041:24: warning: cast to
restricted __le32
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For unicast the hardware sometimes reports MIC errors even though the
frame that it received actually contains a valid MIC - on some chips this
can happen frequently enough to trigger TKIP countermeasures.
Fix this issue by not reporting MIC errors for unicast frames with a
valid key, letting mac80211 validate the MIC instead.

Additionally, strip the MIC for all frames that the hardware considers
valid to avoid wasting CPU cycles re-validating it.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Decryping frames on key_miss handling shouldn't be done for Michael
MIC failed frames as h/w would have already decrypted such frames
successfully anyway.

Also leaving CRC and PHY error(where the frame is going to be dropped
anyway), we are left to prcoess Decrypt error for which s/w decrypt is
selected anway and so having key_miss as a separate check doesn't serve
anything. So making key_miss handling mutually exlusive with other RX
status handling makes much more sense.

This patch addresses an issue with STA not reporting MIC failure events
resulting in STA being disconnected immediately.

Cc: stable@kernel.org
Signed-off-by: NSenthil Balasubramanian <senthilb@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

AR_AN_SYNTH9 is in the analog shift register range and thus needs to be
written using the ath9k_hw_analog_shift_rmw function.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The radio needs twice / four times as much time to stabilize for half/quarter
channels.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The radio seems to perform better that way
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Now that the clock rate is initialized properly and SIFS, EIFS, USEC,
slot time and ACK timeout are properly calculated by the generic code,
the 'async FIFO' register hacks are no longer necessary.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Initialize the the clock-to-TSF field of AR_USEC and the SIFS and EIFS time
registers based on the clock rate instead of relying on initvals.
With those changes, some of the hardcoded AR9287 1.3+ specific overrides
can be dropped.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This chip uses the async FIFO feature and runs the MAC at 117 MHz
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Enabling half/quarter rate makes the MAC run at half/quarter clock speed.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

All devices support this, but some disable it using an EEPROM flag
for some reason. Improves 5 GHz performance on those devices.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Use the proper masks for the register instead.
Fixes adding the (still unused) half/quarter PLL flags.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Recent firmware changes report tx ack status properly
to driver. Hence updating ath9k_htc driver capabilities.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch removes read only registers that cause invalid
address access and also updates index for measurement filter
calibration window size.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The power detector calibration is disabled because this block
doesn't exist in AR9003 based chips and also parallel
calibration is enabled otherwise the calibration will never stop.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The number of temperature reading samples to average
during a Tx packet is decreased to 1 from 2 to improve
5G Tx EVM with chain 0-only mode.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While sending aggregated frames in AES, the AR5416 chips
required additional padding b/w subframes. This workaround
is not needed for edma (AR9003 family) chips. With this patch
~4Mbps thoughput improvement was observed in clear environment.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

for more details please take a look at:
http://comments.gmane.org/gmane.linux.drivers.ath9k.devel/6541
http://www.wikidevi.com/wiki/Sony_UWA-BR100Reported-by: NThomas Novin <thomas@xyz.pp.se>
Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The received tx status of aggregated frame without BlockAck may
cause deaf state in AR5416 cards. So the driver does a reset to
recover. When this happens, we release the pcu_lock before doing
a reset as ath_rest acquires pcu_lock. This is ugly and also not
atomic. Fixing this addresses the TX DMA failure also.

ath_tx_complete_aggr can be called from different paths which
takes different variants of spin_lock. This patch also addresses
the following warning.

WARNING: at kernel/timer.c:1011 del_timer_sync+0x4e/0x50()
Call Trace:
 <IRQ>  [<ffffffff8104be3a>] warn_slowpath_common+0x7a/0xb0
 [<ffffffff8104be85>] warn_slowpath_null+0x15/0x20
 [<ffffffff8105915e>] del_timer_sync+0x4e/0x50
 [<ffffffffa03726be>] ath_reset+0x3e/0x210 [ath9k]
 [<ffffffff8135cdaf>] ? _raw_spin_unlock_bh+0x1f/0x30
 [<ffffffffa037760a>] ath_tx_complete_aggr.isra.26+0x54a/0xa40 [ath9k]
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cc: muddin@qca.qualcomm.com
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The edma based (AR9003 family) chips update tx status
descriptors in a common ring buffer for all transmitted
frames. Whenever tx interrupt is raised, the descriptors
are processed and tx status index is moved.

The complete tx stauts ring are updated with beacons tx status
when there are no data frames to be sent for a period of time.
In this state, transmitting data frames causes the driver to
wait for the tx status on an incorrect tx status index though
the status was updated by hw properly. The driver detects this
condition as a h/w hang and does unnecessary chip resets.

This issue was orginally reported in adhoc mode while sending
frames after an idle time.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>