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