ath10k: reorder functions

This is done to avoid forward declarations with
upcomming patches.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: refactor radar detection code

If 20MHz CAC completed successfully then
subsequent CAC with wider bandwidth (40Mhz, 80Mhz)
with identical control frequency did not start
monitor vdev making it impossible to detect any
radar pulses during intended CAC.

It also was incorrect to assume ath10k_config() will
be called after CAC is finished. Theoretically for
non-HT channels nothing changes between CAC and
start_ap() (albeit in practice this can be
different). The incorrect assumption led to CAC
not being stopped on non-HT chandefs leading to
all Rx being drooped making it impossible for
clients to associate.

While at it clean up the code a bit.

kvalo: separate WARN_ON() from the if statement

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: improve htc tx credit debugging prints

This way it's easier to track and debug htc tx
credit issues.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[RFTv2 1/5] ath10k: always request htc tx replenishment

This simplifies tx credit management and tries to
address a problem where driver runs out of credits
and is unable to recover when firmware stalls.

This also makes it a little more easy to track and
debug htc tx credit flow since there should be no
laziness involved.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[RFTv2 2/5] ath10k: fix wmi-htc tx credit starvation

Each WMI management Tx consumes 1 HTC Tx credit
and doesn't replenish it until the frame is
actually transmitted out of firmware's Tx queues.

If associated client was asleep and has gone out
of range then unicast frames won't be released for
FW/HW queues for a while (10 seconds per
observation). This means that if more management
frames are queued then HTC Tx credits are drained
to 0 and no other commands can be submitted
including beacons and peer removal.

This could in turn result in clients disconnecting
due to their beacon loss and may trigger spurious
sta kickouts because wmi peer removal command may
never reach firmware during disassociation.

This could happen, e.g. when disconnecting
client (hostapd inactivity) that has gone away
while asleep when acting as AP.

As a workaround flush frames that can potentialy
get stuck in FW Tx queues.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[RFTv2 3/5] ath10k: rework peer accounting

It was troublesome to iterate over peers and
perform sleepable calls. This will be necessary
for some upcomming changes to tx flushing.

Make peer allocation and initial setup
protected by both ar->conf_mutex and
ar->data_lock. This way it's possible to iterate
over peers with conf_mutex and call sleepable
functions.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[RFTv2 4/5] ath10k: wait for mgmt tx when flushing too

The 10.1 firmware uses WMI to Tx management frames
but ath10k_flush() didn't care. This could lead to
some frames not being sent.

Although there are no Tx completions for WMI
mangement frames it's still better to at least
wait for ath10k queue to be drained.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[RFTv2 5/5] ath10k: improve tx flushing

Flushing was prone to timeouts when powersaving
clients were involved that went missing while
asleep. The common culprit was NullFunc frame
being stuck in FW/HW queues.

Introduce a two-pass flushing with WMI flush
commands interleaved to force frame drops if
necessary. This allows for a decreased flush
timeout time and should get rid of some warnings.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: differentiate between target init failures

This just makes it easier to tell apart different
kinds of bringup failure.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: don't wait for device init if it crashed

When warm resetting it's possible for device to
crash during initialization. Instead of waiting 3
seconds just return failure as soon as
FW_IND_EVENT_PENDING is set.

This speeds up device bootup and recovery in some
cases.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: skip suspending when recovering

It doesn't make much sense to even try suspending
the device when recovering. Recovering means the
device is unresponsive and waiting for suspend
procedure means taking a 3 second timeout waiting
for tx credits.

This speeds up firmware recovery significantly.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: make sure to not leak beacon dma mapping

If for some reason mac80211 wouldn't stop
beaconing gracefully and just removed interface of
a running AP/IBSS interface it was possible to
leak pending beacon DMA mapping. It's very
unlikely but better safe than sorry.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: make sure to not use invalid beacon pointer

If DMA mapping of next beacon failed it was
possible for next SWBA to access a pointer that
was already unmapped and freed. This could cause
memory corruption.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: prevent beacon memory leak

If DMA mapping of next beacon failed ath10k leaked
the beacon.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: fix firmware recovery with ap interface

Beacon data wasn't properly cleared during early
phase of recovery. This in turn caused firmware to
crash because the beacon data was submitted before
vdevs were fully re-configured. Ultimately the
device was considered wedged and nothing worked
until driver was reloaded.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: double check bmi xfer pointers

If for some reason copy engine ring buffer became
corrupt ath10k could crash the machine due to
invalid pointer dereference. It's very unlikely
but devices can never be fully trusted so verify
if the bmi xfer pointer read back from copy engine
matches the original pointer. The bug looked as
follows:

 BUG: unable to handle kernel paging request at ffffffff815d6133
...
 Call Trace:
 [<ffffffff810fdaf4>] ? mark_held_locks+0x71/0x99
 [<ffffffff810c6b6d>] ? __local_bh_enable_ip+0xaa/0xd9
 [<ffffffff810fd7eb>] lock_acquire+0x82/0x9d
 [<ffffffff810f5999>] ? complete+0x19/0x45
 [<ffffffff810c6b72>] ? __local_bh_enable_ip+0xaf/0xd9
 [<ffffffff815d5f9b>] _raw_spin_lock_irqsave+0x47/0x5a
 [<ffffffff810f5999>] ? complete+0x19/0x45
 [<ffffffff810f5999>] complete+0x19/0x45
 [<ffffffffa056d977>] ath10k_pci_hif_exchange_bmi_msg+0x267/0x3f4 [ath10k_pci]
 [<ffffffffa0471b42>] ath10k_hif_exchange_bmi_msg+0xe/0x10 [ath10k_core]
 [<ffffffffa0471f01>] ath10k_bmi_write_memory+0xc4/0x12d [ath10k_core]
 [<ffffffffa046877f>] ath10k_core_start+0x207/0x828 [ath10k_core]
 [<ffffffffa0469723>] ath10k_core_register+0x5ca/0x77f [ath10k_core]
...

Reported-By: Ben Greear <greearb@candelatech.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>