As soon as the interface brought up, btcoex timer starts running
eventhough the interface is in idle state and WLAN chip is moved
to full sleep mode. There is no point in running btcoex timer when
the wlan interface is in sleep mode and also it might consumes
more power on WLAN idle unassociated state. So lets stop the
btcoex when wlan is idle state.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Wrap the MCI-work canceling with CONFIG_ATH9K_BTCOEX_SUPPORT.
Reported-by: NEmmanuel Benisty <benisty.e@gmail.com>
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Cancel the MCI work only when MCI is actually enabled.
Fixes this:

[96833.124051] Call Trace:
[96833.124060]  [<ffffffff810afaf8>] __lock_acquire+0x1518/0x1e40
[96833.124065]  [<ffffffff810ad126>] ? mark_held_locks+0x86/0x110
[96833.124069]  [<ffffffff810ad3ad>] ? trace_hardirqs_on+0xd/0x10
[96833.124073]  [<ffffffff814464f0>] ? _raw_spin_unlock_irq+0x30/0x70
[96833.124078]  [<ffffffff81072968>] ? wait_on_cpu_work+0x98/0xc0
[96833.124082]  [<ffffffff810b0a11>] lock_acquire+0xa1/0x150
[96833.124085]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124088]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124092]  [<ffffffff810729e2>] wait_on_work+0x52/0x120
[96833.124095]  [<ffffffff81072990>] ? wait_on_cpu_work+0xc0/0xc0
[96833.124099]  [<ffffffff81063b3f>] ? del_timer+0x7f/0x110
[96833.124102]  [<ffffffff81072c13>] __cancel_work_timer+0x83/0x130
[96833.124106]  [<ffffffff81072cf0>] cancel_work_sync+0x10/0x20
[96833.124113]  [<ffffffffa065b5cd>] __ath_cancel_work+0x4d/0x60 [ath9k]
[96833.124119]  [<ffffffffa065cf28>] ath9k_config+0x458/0x680 [ath9k]
[96833.124125]  [<ffffffffa065dd1e>] ? ath9k_flush+0x6e/0x1d0 [ath9k]
[96833.124129]  [<ffffffff8144394d>] ? __mutex_unlock_slowpath+0x10d/0x190
[96833.124146]  [<ffffffffa056c7b5>] ieee80211_hw_config+0x135/0x2a0 [mac80211]
[96833.124163]  [<ffffffffa057ebbb>] ieee80211_do_open+0x67b/0xc50 [mac80211]
[96833.124178]  [<ffffffffa057f1fd>] ieee80211_open+0x6d/0x80 [mac80211]
[96833.124183]  [<ffffffff8137a44f>] __dev_open+0x9f/0xf0
[96833.124187]  [<ffffffff8137a701>] __dev_change_flags+0xa1/0x180
[96833.124190]  [<ffffffff8137a898>] dev_change_flags+0x28/0x70
[96833.124195]  [<ffffffff813e1179>] devinet_ioctl+0x659/0x780
[96833.124199]  [<ffffffff8137aea0>] ? dev_ioctl+0x210/0x6d0
[96833.124203]  [<ffffffff813e1db5>] inet_ioctl+0x75/0x90
[96833.124208]  [<ffffffff8135e0e0>] sock_do_ioctl+0x30/0x70
[96833.124211]  [<ffffffff8135e3dd>] sock_ioctl+0x7d/0x2c0
[96833.124218]  [<ffffffff81193c39>] do_vfs_ioctl+0x99/0x580
[96833.124222]  [<ffffffff81447415>] ? sysret_check+0x22/0x5d
[96833.124226]  [<ffffffff811941b9>] sys_ioctl+0x99/0xa0
[96833.124230]  [<ffffffff814473e9>] system_call_fastpath+0x16/0x1b
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 adds stations in HT IBSS as soon as a frame comes by,
even if the HT capabilities are not known yet (they are often
received later, e.g. in beacons). So far, ampdu factor/density
are only calculated when the station is initially added.

This patch changes this to update ampdu factor/density settings
when starting a blockack session.

Using this patch, we had performance boosts from 60 to 150 MBit/s
between two 2x2 Atheros devices in 5 GHz HT IBSS mode.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The new ANI implementation does not need it
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As btcoex scheme updation might sleep, remove the function call
from tasklet context and queue it up as a separate work.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Not doing so, could cause imbalance in powersave count.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

steps to recreate:
load latest ath9k driver with AR9485
stop the network-manager and wpa_supplicant
bring the interface up

	Call Trace:
	[<ffffffffa0517490>] ? ath_hw_check+0xe0/0xe0 [ath9k]
	[<ffffffff812cd1e8>] __const_udelay+0x28/0x30
	[<ffffffffa03bae7a>] ar9003_get_pll_sqsum_dvc+0x4a/0x80 [ath9k_hw]
	[<ffffffffa05174eb>] ath_hw_pll_work+0x5b/0xe0 [ath9k]
	[<ffffffff810744fe>] process_one_work+0x11e/0x470
	[<ffffffff8107530f>] worker_thread+0x15f/0x360
	[<ffffffff810751b0>] ? manage_workers+0x230/0x230
	[<ffffffff81079af3>] kthread+0x93/0xa0
	[<ffffffff815fd3a4>] kernel_thread_helper+0x4/0x10
	[<ffffffff81079a60>] ? kthread_freezable_should_stop+0x70/0x70
	[<ffffffff815fd3a0>] ? gs_change+0x13/0x13

ensure that the PLL-WAR for AR9485/AR9340 is executed only if the STA is
associated (or) IBSS/AP mode had started beaconing. Ideally this WAR
is needed to recover from some rare beacon stuck during stress testing.
Before the STA is associated/IBSS had started beaconing, PLL4(0x1618c)
always seem to have zero even though we had configured PLL3(0x16188) to
query about PLL's locking status. When we keep on polling infinitely PLL4's
8th bit(ie check for PLL locking measurements is done), machine hangs
due to softlockup.

fixes https://bugzilla.redhat.com/show_bug.cgi?id=811142Reported-by: NRolf Offermanns <rolf.offermanns@gmx.net>
Cc: stable@vger.kernel.org [3.0+]
Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

'cfg80211: fix interface combinations' ensures that if an interface
type is not advertised by the driver in any of the interface combinations
(via ieee80211_iface_combination) then it shall be treated as a single
incompatible interface. if there are more than one interfaces present
and changing them to incompatible interface type is not possible.
These checks will be properly handled by cfg80211_change_iface ->
cfg80211_can_change_interface.

this patch is dependent on 'cfg80211: fix interface combinations'
Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

this patch is dependent on the patch "cfg80211: fix interface
combinations"

In ath9k currently we have ADHOC interface as a single incompatible
interface. when drv_add_interface is called during resume we got to
consider number of vifs already present in addition to checking the
drivers 'opmode' information about ADHOC.  we incorrectly assume
an ADHOC interface is already present. Then we may miss some driver
specific data for the ADHOC interface after resume.

The above mentioned checks can be removed from the driver,
as the patch 'cfg80211: fix interface combinations' ensures that
if an interface type is not advertised by the driver in any of the
interface combinations(via ieee80211_iface_combination) then it shall
be treated as a single incompatible interface. Fixes the following
warning on suspend/resume with ibss interface.

        ath: phy0: Cannot create ADHOC interface when other
        interfaces already exist.
        WARNING: at net/mac80211/driver-ops.h:12
        ieee80211_reconfig+0x1882/0x1ca0 [mac80211]()
        Hardware name: 2842RK1
        wlan2:  Failed check-sdata-in-driver check, flags: 0x0

        Call Trace:
        [<c01361b2>] warn_slowpath_common+0x72/0xa0
        [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [<f8aaa7c2>] ? ieee80211_reconfig+0x1882/0x1ca0
        [mac80211]
        [<c0136283>] warn_slowpath_fmt+0x33/0x40
        [<f8aaa7c2>] ieee80211_reconfig+0x1882/0x1ca0 [mac80211]
        [<c06c1d1a>] ? mutex_lock_nested+0x23a/0x2f0
        [<f8a95097>] ieee80211_resume+0x27/0x70 [mac80211]
        [<fd177edf>] wiphy_resume+0x8f/0xa0 [cfg80211]

Cc: stable@vger.kernel.org
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>

After a chip reset, the beacon timers have to re-programmed
correctly for a station in associated state. Use the PS flags
to ensure that this is done after a TSF sync happens, otherwise
the driver ends up using incorrect values for TBTT/DTIM in
powersave mode.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The 'ps_flags' is used/accessed in a variety of contexts
and requires proper locking. Use 'sc_pm_lock' appropriately.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a fatal interrupt is received or it is detected that the baseband
has hung, the chip has to be reset immediately.  Otherwise, we end up
processing spurious interrupts. Ensure that we bail out properly in
the ISR when the reset work hasn't completed yet.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The 'sc_flags' variable is being used in a number of places
with no locking whatsoever. This patch converts the usage
of sc_flags to atomic ops.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

And use a helper function to setup antennae after a reset.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* Currently, there is no synchronization between the reset
  work and the tx-poll work. Fix this and make sure that we
  bail out properly if a reset work is in progress.

* Cleanup the PLL WAR and enable it for AR9340 too and
  use a helper for restarting work/timers after a reset.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add link.c and move all the link/connection monitoring
code to it.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the chip is waking up from sleep state, the cycle counters
might have incorrect readings. So it is better not to update those
readings with software counters.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211's IEEE80211_CONF_OFFCHANNEL can be used directly
to track offchannel state. Also pass the correct boolean
value to ath9k_hw_startpcureceive().
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

MCI interrupts have to be enabled only when BTCOEX is
actually in use.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This returns many of the values that formerly could
only be obtained from debugfs.  This should be an
improvement when trying to access these counters
programatically.  Currently this support is only
enabled when DEBUGFS is enabled because otherwise
these stats are not accumulated.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It has been found that active Rx can interfere with stopping tx DMA, which
could result in at least parts of those "Failed to stop Tx DMA!" messages.
Stopping rx before tx should prevent that.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

* PS_WAIT_FOR_TX_ACK is used in network-sleep mode and checking
  it for handling IDLE transitions is incorrect. Fix this.

* RX PCU/DMA engines have to be stopped before setting the chip into
  full-sleep mode - otherwise the chip becomes mute.

* Make things a bit clear by checking explicitly for network-sleep
  mode in the tx() routine and add a couple of debug statements
  to aid PS debugging.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As of now beacon configuration is being called multiple times
in bss info change notification. This patch avoids multiple
configuration and make it simpler.
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since it's only called when beacons are stuck, move it to the SWBA handler
tasklet, to avoid doing redundant checks on every single interrupt.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The hardware needs a reset to recover from full sleep. Issue this reset
directly in the ath9k_config call that turns off idle, otherwise tx
remains dead until the first channel change after the idle state change
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This counts any failure during getting packets into
the DMA buffers, including out-of-memory, etc.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit c1afdaff.

Users have reported connection failures in 3.3.1 and suspend/resume
failures in 3.4-rcX. Revert this commit for now - PS IDLE can be
fixed in a clean manner later on.

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

In the experiment with Azimuth ADEPT-n testbed where the APs transmit
power was reduced to 25% and the signal strength was futher attenuated
by 20dB and induced a path loss of ~7dB, the station was reporting
beacon losses and the following issue were observed.

* rx clear is stuck at low for more than 300ms
* dcu chain and complete state is stuck at one of the hang signature

This patch triggers the hang detection logic that recovers the chip
from any of the above conditions. As the issue was originally reported
in ChromeOs with AR9382 chips, this detection logic is enabled only for
AR9380/2 chips.

Cc: Paul Stewart <pstew@google.com>
Reported-by: NGary Morain <gmorain@google.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The commit "ath9k: Remove aggregation flags" changed how
nodes were being initialized. Use the HW HT cap bits
to initialize/de-initialize nodes, else we would be
accessing an uninitialized entry during a suspend/resume cycle,
resulting in a panic.
Reported-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 provides short preamble information and ERP protection
information on a per-BSS basis, which can be used. Remove flags
stored in the driver, which was incorrect since they were being used
in a global manner.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

SC_OP_TXAGGR and SC_OP_RXAGGR are not really needed.
The HT capabilities of the station and HW can be used instead.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The logic to determine whether to use FCC is a bit convoluted.
Use a small helper function to decide whether FCC is to be
used.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

It is not needed and will not be used anyway since
unsupported interfaces are not allowed to be created.
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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

There is no need to mask out SWBA/BMISS from the
interrupt mask in start().
Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The check for PS_WAIT_FOR_TX_ACK was inverted, the hardware should only go
to full sleep if no tx is pending.
Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The proper place to configure bss info is at assoc notification. So that
ath9k continues to work if the supirous bssid notification will be
removed in future.

Cc: Johannes Berg <johannes@sipsolutions.net>
Reported-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since AR9003 uses a global tx status queue, processing tx status outside of
the regular tx tasklet is dangerous and messes up hardware/software
synchronization of tx status events.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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