From: Mehmet Fide <mehmet.fide@gmail.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com>,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
mehmet.fide@screeningeagle.com
Subject: [PATCH rtw-next v7 0/3] wifi: rtw88: channel switch in AP mode
Date: Tue, 20 Oct 2026 22:47:09 +0200 [thread overview]
Message-ID: <20261020204712.3252023-1-mehmet.fide@gmail.com> (raw)
From: Mehmet Fide <mehmet.fide@screeningeagle.com>
An rtw88 AP cannot change its channel: the driver does not announce
channel switch support, so hostapd's CHAN_SWITCH is refused and the
only way is to tear the AP down. The series fixes the beacon download
the reserved page build makes twice, implements channel_switch_beacon
on top of the firmware's beacon page, and times the countdown
downloads from the TBTT so that every count goes out on the air.
Tested on an RTL8821CU, an RTL8822CU and an RTL8822BU (USB) with
hostapd 2.10 as AP: switches with counts 1 to 100, scans during a
countdown, hostapd stopped and started, the USB driver unbound and
bound and a firmware crash during a countdown, IBSS switches, a
station interface on the 8822CU associating while its AP counted
down, and Windows and Linux stations following the switches without a
re-association. The 8821CU and 8822CU set was run on a PROVE_LOCKING
kernel without a lockdep report.
Patch 3 was tested on the RTL8821CU with a build that delays every
second countdown download: with a 60 ms delay every count still goes
out (sniffed from a third machine), with 95 ms the delayed count
stays out and the next download follows at once; the AP finishes at
the same time in both cases, and a Windows station followed the
switches with counts 10 and 50 without a re-association. With the
start forced to either side of a TBTT, and with iperf3 traffic, the
counts matched the beacon timing in every run on the RTL8821CU and on
the RTL8822BU, the first on a PREEMPT_RT kernel, the second on a
preemptible one without RT, both with HZ=250. The patch 2 fix was
checked with a build that queues a TIM update right after every
countdown finish: the WARN came before the fix and not after it.
Patch 1 is unchanged since v6.
v7:
- new patch 3: the countdown downloads are timed from the TSF, 10 ms
after each TBTT, so a download that runs late by less than a beacon
interval still reaches the firmware before the next beacon; one
later than that is followed by its successor at once. Ping-Ke's
question on v6: with the absolute due time a late download and its
successor could land in one beacon period and leave a count out of
the air
- patch 3 takes a TBTT within the margin before the start as the one
that sent the countdown template: a TBTT between the template
download and the first TSF read made the stations see one count
twice
- patch 2 keeps csa_vif until the beacon after the switch: a TIM
update before it fetched one beacon past count 1 and hit the WARN
in ieee80211_beacon_update_cntdwn()
- rebased on rtw-next
v6:
- the wiphy work patch of v5 is gone: the countdown work is an
ieee80211 delayed work and csa_vif is driver state, both under the
driver mutex, so rtw88 takes no wiphy lock anywhere (Ping-Ke)
- rtw_core_stop() cancels the countdown work and clears csa_vif, which
covers the IPS path and the firmware recovery; the wiphy_lock() in
the recovery work is gone (Ping-Ke)
- the BSS_CHANGED_BEACON path says why it starts the countdown, the
replay after a hardware restart, and stops it when the beacon comes
back without a switch announced (Ping-Ke)
- the downloads are paced from the first one with an absolute due
time. Queued after each download, they drifted by about 10 ms per
beacon interval on the ordered mac80211 workqueue; on a count of 50
the AP switched half a second after its station had, and the
station re-associated
v5:
- 2/3 is new: update_beacon_work becomes a wiphy work, so that it can
look at the channel switch state under the wiphy lock; it checks
RTW_FLAG_RUNNING instead of being cancelled in rtw_core_stop(), which
runs without the wiphy lock on the IPS path (Ping-Ke); reverted in v6
- 3/3: rtw_fw_csa_active/start/stop() assert the wiphy lock (Ping-Ke);
reverted in v6, they assert the driver mutex
- 3/3: hw_scan() takes the mutex with guard() (Ping-Ke)
- 3/3: a comment on the association download names the STA+AP
combination it skips the download for (Ping-Ke)
- the whole set ran on a PROVE_LOCKING kernel without a lockdep report:
switches with counts 1 to 100, hostapd stopped and restarted during
a countdown, scans during a countdown, a firmware crash during a
countdown, three stop/idle/start cycles, IBSS, 50 switches with a
station attached, and on the RTL8822CU a station interface
associating while the AP interface counted down
v4:
- 1/2: Reviewed-by from Luka
- 2/2: the countdown work is back in the device, initialised once,
with csa_vif naming the interface; no interface iteration and no
lookup through the reserved page any more (Ping-Ke)
- 2/2: the countdown is cancelled before a firmware recovery restarts
the hardware, instead of guarding the work with flags (Ping-Ke)
- 2/2: the page download on association skips a running countdown,
like the TIM update and the PG backup (Luka)
- 2/2: the scan refusal comes before the scan offload test, so that
firmware without scan offload does not fall back to a software scan
during a countdown (Luka)
v3:
- 1/2: the beacon out-pointer is initialised in the caller (Luka)
- 2/2: the countdown work lives in the interface, remove_interface
cancels it unconditionally, the queue wrapper and the comments are
gone (Ping-Ke)
- 2/2: the TIM update and the PG backup on set_key skip the page
download while a switch is announced; every beacon fetch advances
the countdown (Luka)
- 2/2: the commit message names the refused hardware scan (Ping-Ke)
v2:
- 2/2: a hardware scan is refused while a switch is announced
- the rtw89 mention is gone from the cover
Mehmet Fide (3):
wifi: rtw88: download the beacon the reserved page was built with
wifi: rtw88: support channel switch in AP mode
wifi: rtw88: time the countdown downloads from the TBTT
drivers/net/wireless/realtek/rtw88/fw.c | 146 ++++++++++++++++--
drivers/net/wireless/realtek/rtw88/fw.h | 4 +
drivers/net/wireless/realtek/rtw88/mac80211.c | 39 ++++-
drivers/net/wireless/realtek/rtw88/main.c | 6 +-
drivers/net/wireless/realtek/rtw88/main.h | 3 +
drivers/net/wireless/realtek/rtw88/reg.h | 1 +
6 files changed, 178 insertions(+), 21 deletions(-)
base-commit: 9b0be45d4d52fd223994e151f169743a97abd290
--
2.55.0
next reply other threads:[~2026-10-20 20:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 20:47 Mehmet Fide [this message]
2026-10-20 20:47 ` [PATCH rtw-next v7 1/3] wifi: rtw88: download the beacon the reserved page was built with Mehmet Fide
2026-10-20 20:47 ` [PATCH rtw-next v7 2/3] wifi: rtw88: support channel switch in AP mode Mehmet Fide
2026-10-20 20:47 ` [PATCH rtw-next v7 3/3] wifi: rtw88: time the countdown downloads from the TBTT Mehmet Fide
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261020204712.3252023-1-mehmet.fide@gmail.com \
--to=mehmet.fide@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mehmet.fide@screeningeagle.com \
--cc=pkshih@realtek.com \
--cc=rtl8821cerfe2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®