ath10k: don't drop control and null func Rx

HTT_RX_IND_MPDU_STATUS_MGMT_CTRL was pretty greedy
and because of that ath10k ended up dropping
Control Frames as well as Null Func frames.

Reported-by: Okhwan Lee <ohlee@mwnl.snu.ac.kr>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: remove unused variable

The rx descriptor variable was no longer used in
the rx handler.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: use ieee80211 defines for crypto param lengths

Use the globally defined ieee80211 values instead
of re-defining them in the driver again.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: fix rx buffer tracing

Tracing function was called before buffers were
unmapped from DMA.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: deduplicate htt rx dma unmapping

Treat non-chained and chained popping the same
way. Also this makes netbuf pop fully symmetrical
to (re)filling.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: don't drop frames aggressively

There's little point in dropping, e.g. frames with
FCS error early in ath10k.

This simplifies amsdu_allowed() and gets rid of
htt_rx_mpdu_status usage finally.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: add extra sanity check when popping amsdu

The netbuf pop can return NULL. Make sure to check
for that. It shouldn't happen but better safe than
sorry.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: don't forget to replenish after fragmented Rx

In theory it was possible to drain entire HTT Rx
ring via fragmented Rx leading to Rx lockup.

In practice non-data traffic would always trigger
replenishment via the regular Rx handler.

For correctness sake make sure to replenish the
ring on fragmented Rx.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: clear htt->rx_confused on load

Once driver entered the rx_confused state it would
refuse to rx even after firmware is restarted.
Make sure to clear it so that rx works after, e.g.
hw restart or after all interfaces are stopped.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: remove tsf argument from rx_desc tracing

Fundamentally this was wrong. Tsf is only valid
in last MPDU of a PPDU. This means tsf value was
wrong most of the time during heavy traffic.

Also I don't see much point in exposing a
redundant (and broken) tsf value. Userspace can
already read it from the dumped rx descriptor
buffer.

Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: re-use trace class

Instead of defining a completely new tracepoint
use an existing tracepoint class.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: add SURVEY_INFO_IN_USE for current channel on survey

When user space requests survey info, it is useful to know which of the survey
data refers to the channel that is currently actively being used.  One of the
use cases is getting the current channel noise for status output.  Without this
flag you would have to look up the channel separately and then compare it
against the frequency in the survey output in user space.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: call correct function for frag threshold

Rts threshold was being configured instead of
fragmentation threshold.

Keep in mind available firmware binaries don't
seem to support fragmentation anyway so this
doesn't fix fragmentation threshold per se.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: avoid possible deadlock with scan timeout

This should prevent deadlock predicted by the
following splat:

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.17.0-wl-ath+ #67 Not tainted
 -------------------------------------------------------
 kworker/u32:1/7230 is trying to acquire lock:
  (&ar->conf_mutex){+.+.+.}, at: [<ffffffffa040a57d>] ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]

 but task is already holding lock:
  ((&(&ar->scan.timeout)->work)){+.+...}, at: [<ffffffff8106dae1>] process_one_work+0x151/0x470

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 ((&(&ar->scan.timeout)->work)){+.+...}:
        [<ffffffff810a12e5>] lock_acquire+0x85/0x100
        [<ffffffff8106cb4d>] flush_work+0x3d/0x270
        [<ffffffff8106e49d>] __cancel_work_timer+0x7d/0x110
        [<ffffffff8106e543>] cancel_delayed_work_sync+0x13/0x20
        [<ffffffffa0409f16>] ath10k_cancel_remain_on_channel+0x36/0x60 [ath10k_core]
        [<ffffffffa028c75c>] ieee80211_cancel_roc+0x1cc/0x2f0 [mac80211]
        [<ffffffffa028c8a2>] ieee80211_mgmt_tx_cancel_wait+0x22/0x30 [mac80211]
        [<ffffffffa0132288>] nl80211_tx_mgmt_cancel_wait+0xa8/0x130 [cfg80211]
        [<ffffffff816654a5>] genl_family_rcv_msg+0x1a5/0x3c0
        [<ffffffff81665749>] genl_rcv_msg+0x89/0xc0
        [<ffffffff81664e91>] netlink_rcv_skb+0xb1/0xc0
        [<ffffffff816650bc>] genl_rcv+0x2c/0x40
        [<ffffffff8166474d>] netlink_unicast+0x18d/0x200
        [<ffffffff81664add>] netlink_sendmsg+0x31d/0x430
        [<ffffffff8161a9ac>] sock_sendmsg+0x9c/0xd0
        [<ffffffff8161b469>] ___sys_sendmsg+0x389/0x3a0
        [<ffffffff8161bed9>] __sys_sendmsg+0x49/0x90
        [<ffffffff8161bf32>] SyS_sendmsg+0x12/0x20
        [<ffffffff8174c456>] system_call_fastpath+0x1a/0x1f

 -> #0 (&ar->conf_mutex){+.+.+.}:
        [<ffffffff810a0bde>] __lock_acquire+0x1b6e/0x1ce0
        [<ffffffff810a12e5>] lock_acquire+0x85/0x100
        [<ffffffff817491eb>] mutex_lock_nested+0x4b/0x370
        [<ffffffffa040a57d>] ath10k_scan_timeout_work+0x2d/0x50 [ath10k_core]
        [<ffffffff8106db41>] process_one_work+0x1b1/0x470
        [<ffffffff8106df63>] worker_thread+0x123/0x460
        [<ffffffff81073f34>] kthread+0xe4/0x100
        [<ffffffff8174c3ac>] ret_from_fork+0x7c/0xb0

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock((&(&ar->scan.timeout)->work));
                                lock(&ar->conf_mutex);
                                lock((&(&ar->scan.timeout)->work));
   lock(&ar->conf_mutex);

  *** DEADLOCK ***

Reported-by: Marek Puzyniak <marek.puzyniak@tieto.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: change ce ring cleanup logic

Make ath10k_pci_init_pipes() effectively only
alter shared target-host data.

The per_transfer_context is a host-only thing.
It is necessary to preserve it's contents for a
more robust ring cleanup.

This is required for future warm reset fixes.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: make warm reset a bit safer and faster

One of the problems with warm reset I've found is
that it must be guaranteed that copy engine
registers are not being accessed while being
reset. Otherwise in worst case scenario the host
may lock up.

Instead of using sleeps and hoping the device is
operational in some arbitrary timeframes use
firmware indication register.

As a side effect this makes driver
boot/stop/recovery faster.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: split reset logic from power up

The power up procedure was overly complex due to
warm/cold reset workarounds and issues.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: don't reset chip on power_down

Currently hif_power_up performs effectively a
reset and hif_stop resets the chip as well so
there's no point in resetting here.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: fix possible bmi crash

While testing other things I've found that CE
items aren't cleared properly. This could lead to
null dereferences in BMI.

To prevent that make sure CE revoking clears the
nbytes value (which is used as a buffer completion
indication) and memset the entire CE ring data
shared between host and target when
(re)initializing.

Also make sure to check BMI xfer pointer and print
a splat instead of crashing the kernel.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
ath10k: expose hw restart via debugfs

Until now it was possible to simulate soft and
hard fw crashes but it wasn't possible to trigger
an immediately hw restart itself (without the fw
crash).

This can be useful when stress testing hw
restarting stability, e.g. during heavy tx/rx
traffic.

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