[PATCH v3 0/5] wifi: ath9k: cut USB round trips on channel changes

["Nerijus Bendžiūnas" <nerijus.bendziunas@gmail.com>]

On the ath9k_htc devices every register access is a synchronous WMI
round trip, so a channel change that is cheap on PCI costs tens of
milliseconds over USB. This series removes round trips from that path
without changing the register values written.

Patch 1 is a fix: a multi-read that fails over USB hands the caller
uninitialised stack data; make it return all ones like a single read.
Patch 2 gives the 8-register limit of REG_READ_MULTI() a name and
checks it. Patch 3 replaces the per-queue ath9k_hw_numtxpending() loop
in ath9k_hw_channel_change() with two multi-reads and needs patch 1 so
that a failed read still counts as pending. Patch 4 wraps the
read-modify-write runs in ar5008_hw_set_delta_slope() and
ath9k_hw_start_nfcal() in the RMW buffer. Patch 5 skips the departing
channel's noise floor readout on a fast channel change over USB.

Patches 3 and 4 touch code that PCI runs too, but there the multi-read
is a loop of single reads and the RMW buffer callbacks are not
installed, so the register traffic is unchanged. Patch 5 is limited to
ATH_USB.

Measured on an AR9271 (0cf3:9271) with a local counter of WMI commands
around the driver's channel change:

                                   WMI commands     time
  full reset, unpatched                     182   ~92 ms
  fast channel change, patches 1-5           44   ~31 ms

The second row also depends on two changes outside this series: taking
the fast path on same-band retunes, which mainline does only for
off-channel scan hops, and the mac80211 change that makes a monitor
retune one driver channel change instead of two [1]. On mainline the
reduction therefore shows up on scan hops.

Two further patches that skipped the PCU re-initialisation and the
WMI_SET_MODE on a fast change were dropped before v1: the receiver
stopped delivering frames, because ath9k_host_rx_init() is what clears
AR_DIAG_RX_DIS and AR_DIAG_RX_ABORT. With patches 1-5 the fast path
delivered 90-97% of frames injected from a second AR9271 over coax on
the 2.4 GHz channels, against 95-97% for a full reset on the same
build. The spread is run-to-run drift of the rig; the fast path shows
it first because it does not recalibrate, which is also why mainline
limits that path to scan hops.

[1] https://lore.kernel.org/linux-wireless/20260904032235.355479-1-nerijus.bendziunas@gmail.com/

Changes in v3:
- Move the fail-safe multi-read fix to the front of the series and Cc
  stable, so it can be picked on its own.
- Patch 2: report an over-long multi-read as failed (all ones) instead
  of returning with the buffer untouched; comment reworded.
- Patch 3: kernel-doc for ath9k_hw_first_txpending().
- Add Assisted-by, rewrite the commit messages, rebase onto ath-next.

Changes in v2:
- New fail-safe multi-read patch: ath9k_multi_regread() copies an
  uninitialised buffer out when the command fails. In v1 that made the
  queue check random on a timeout; it also affects the ANI, EEPROM and
  register array callers, so it is fixed separately with a Fixes tag.
- Queue check: comment on why a failed read is safe.
- Other patches unchanged.

Nerijus Bendžiūnas (5):
  wifi: ath9k_htc: report a failed multi-read as all ones
  wifi: ath9k: name the register multi-read limit
  wifi: ath9k: check all tx queues with one multi-read
  wifi: ath9k: batch the read-modify-writes of a channel change
  wifi: ath9k: skip the old channel's noise floor on USB fast changes

 drivers/net/wireless/ath/ath9k/ar5008_phy.c   |  2 +
 drivers/net/wireless/ath/ath9k/calib.c        |  2 +
 drivers/net/wireless/ath/ath9k/htc_drv_init.c | 12 +++++-
 drivers/net/wireless/ath/ath9k/hw.c           | 21 ++++++----
 drivers/net/wireless/ath/ath9k/hw.h           |  7 ++++
 drivers/net/wireless/ath/ath9k/mac.c          | 40 +++++++++++++++++++
 drivers/net/wireless/ath/ath9k/mac.h          |  1 +
 7 files changed, 75 insertions(+), 10 deletions(-)


base-commit: 1d8e73163ef933624341075f576e2f36ef9133f7
-- 
2.55.0