* [BUG] ath12k: CSA with blocktx disrupts TX on other bands
@ 2026-02-04 16:31 Remi Pommarel
0 siblings, 0 replies; only message in thread
From: Remi Pommarel @ 2026-02-04 16:31 UTC (permalink / raw)
To: ath12k; +Cc: Remi Pommarel
Hi,
With the single phy changes introduced for MLO support, both 2.4 GHz
and 5 GHz interfaces on the same dual-band chip now share the same
hardware queues, even when operating on separate bands.
As a result, when a Channel Switch Announcement (CSA) with blocktx
is triggered on one interface (e.g., the 5 GHz vif),
ieee80211_vif_block_queues_csa() pauses the shared HW queues. This
unintentionally blocks TX traffic on the other interface (e.g., the
2.4 GHz vif), despite it being on a different band.
I haven't tested it, but the same issue is expected to affect a single
MLO AP setup, where a CSA could inadvertently pause transmission across
all links.
To address this class of problem, the IEEE80211_HW_HANDLES_QUIET_CSA
flag was introduced. When set, it delegates queue pausing to the
firmware, avoiding unnecessary disruptions in multi-vif or MLO
scenarios. This approach is already used in iwlwifi/mvm, as seen in
commit bbd6d0f8bc51 ("wifi: iwlwifi: mvm: advertise
IEEE80211_HW_HANDLES_QUIET_CSA").
Thus, does the current ath12k firmware properly handle TX quiescing
allowing IEEE80211_HW_HANDLES_QUIET_CSA to be set ? Or does it need
to be handle at the driver level (likewise what has been done in
iwlwifi/mvm in the commit above) ?
Thanks.
--
Remi
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-02-04 16:49 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-04 16:31 [BUG] ath12k: CSA with blocktx disrupts TX on other bands Remi Pommarel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.