[PATCH rtw-next 0/2] wifi: rtw88: channel switch in AP mode

[PATCH rtw-next 0/2] wifi: rtw88: channel switch in AP mode

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

hostapd's CHAN_SWITCH fails on an rtw88 AP because the driver does not
announce channel switch support, so the only way to move the AP to
another channel is to stop and start it, and every client drops.

This adds the support the way rtw89 has it (edba3f107844 "wifi: rtw89:
implement channel switch support"): WIPHY_FLAG_HAS_CHANNEL_SWITCH and a
channel_switch_beacon op that keeps the beacon in the firmware's
reserved page current while the countdown runs, then calls
ieee80211_csa_finish().

The first patch is needed for that: rtw_fw_download_rsvd_page() fetched
the beacon from mac80211 twice per update, once for the page and once
for the standalone beacon download, which advanced the CSA countdown
twice per beacon interval. It now downloads the beacon the page was
built with.

Tested on 6.12.111 with identical hunks, hostapd 2.11 on nl80211:
- RTL8821CU (Edimax AC600, fw 24.11.0) and RTL8822BU (Edimax EW-7822ULC,
  fw 27.2.0) as an AP on arm64 hosts, with one and with two associated
  clients (an AR9271 and an RTL8822BU station).
- CHAN_SWITCH with count 1: the radio moves within 0.6 s, the client
  re-associates as expected without a CSA element.
- count 2, 3 and 5: CSA announced, AP-CSA-FINISHED, radio on the new
  channel within 0.8 s, the clients stay associated with no packet
  loss (worst round trip 168 ms); an iperf3 stream on one of them ran
  on through the switch.
- a countdown aborted by stopping hostapd or unloading the modules:
  clean; STA mode scan: fine; no warning in dmesg in any run.
- every rtw88 chip option built with W=1 and sparse.

Mehmet Fide (2):
  wifi: rtw88: download the beacon the reserved page was built with
  wifi: rtw88: support channel switch in AP mode

 drivers/net/wireless/realtek/rtw88/fw.c       | 54 +++++++++++++++----
 drivers/net/wireless/realtek/rtw88/fw.h       |  1 +
 drivers/net/wireless/realtek/rtw88/mac80211.c | 14 +++++
 drivers/net/wireless/realtek/rtw88/main.c     |  3 +-
 drivers/net/wireless/realtek/rtw88/main.h     |  2 +
 5 files changed, 64 insertions(+), 10 deletions(-)

-- 
2.55.0

[PATCH rtw-next 1/2] wifi: rtw88: download the beacon the reserved page was built with

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

rtw_fw_download_rsvd_page() downloads the beacon twice: once as part of
the reserved page and once more on its own, so that the firmware ends up
with a TX descriptor that describes the beacon rather than the whole
page. The second download fetched a new beacon from mac80211 instead of
downloading the one the page already holds.

Besides the extra work, every beacon fetch advances the DTIM count and,
while a channel switch is announced, the CSA countdown; doing it twice
per update lets a countdown that starts at 2 reach 0, which mac80211
warns about. Keep the beacon skb from the page build and download that.

Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
---
 drivers/net/wireless/realtek/rtw88/fw.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index 945fedcd375b..a4400ff51372 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -1702,11 +1702,13 @@ static u8 *rtw_build_rsvd_page(struct rtw_dev *rtwdev, u32 *size)
 	list_for_each_entry(rsvd_pkt, &rtwdev->rsvd_page_list, build_list) {
 		rtw_rsvd_page_list_to_buf(rtwdev, page_size, page_margin,
 					  page, buf, rsvd_pkt);
-		if (page == 0)
+		if (page == 0) {
 			page += rtw_len_to_page(rsvd_pkt->skb->len +
 						tx_desc_sz, page_size);
-		else
-			page += rtw_len_to_page(rsvd_pkt->skb->len, page_size);
+			/* keep the beacon for rtw_download_beacon() */
+			continue;
+		}
+		page += rtw_len_to_page(rsvd_pkt->skb->len, page_size);
 
 		kfree_skb(rsvd_pkt->skb);
 		rsvd_pkt->skb = NULL;
@@ -1725,7 +1727,6 @@ static u8 *rtw_build_rsvd_page(struct rtw_dev *rtwdev, u32 *size)
 
 static int rtw_download_beacon(struct rtw_dev *rtwdev)
 {
-	struct ieee80211_hw *hw = rtwdev->hw;
 	struct rtw_rsvd_page *rsvd_pkt;
 	struct sk_buff *skb;
 	int ret = 0;
@@ -1744,25 +1745,25 @@ static int rtw_download_beacon(struct rtw_dev *rtwdev)
 		return -EINVAL;
 	}
 
-	skb = rtw_get_rsvd_page_skb(hw, rsvd_pkt);
+	/* the beacon kept by rtw_build_rsvd_page() */
+	skb = rsvd_pkt->skb;
 	if (!skb) {
 		rtw_err(rtwdev, "failed to get beacon skb\n");
-		return -ENOMEM;
+		return -ENOENT;
 	}
 
 	ret = rtw_download_drv_rsvd_page(rtwdev, skb->data, skb->len);
 	if (ret)
 		rtw_err(rtwdev, "failed to download drv rsvd page\n");
 
-	dev_kfree_skb(skb);
-
 	return ret;
 }
 
 int rtw_fw_download_rsvd_page(struct rtw_dev *rtwdev)
 {
-	u8 *buf;
+	struct rtw_rsvd_page *rsvd_pkt;
 	u32 size;
+	u8 *buf;
 	int ret;
 
 	buf = rtw_build_rsvd_page(rtwdev, &size);
@@ -1791,6 +1792,12 @@ int rtw_fw_download_rsvd_page(struct rtw_dev *rtwdev)
 free:
 	kfree(buf);
 
+	/* free the beacon kept by rtw_build_rsvd_page() */
+	rsvd_pkt = list_first_entry(&rtwdev->rsvd_page_list,
+				    struct rtw_rsvd_page, build_list);
+	kfree_skb(rsvd_pkt->skb);
+	rsvd_pkt->skb = NULL;
+
 	return ret;
 }
 
-- 
2.55.0

Re: [PATCH rtw-next 1/2] wifi: rtw88: download the beacon the reserved page was built with

[Luka Gejak]

On Tue, 29 Sep 2026, Mehmet Fide wrote:

> Besides the extra work, every beacon fetch advances the DTIM count and,
> while a channel switch is announced, the CSA countdown; doing it twice
> per update lets a countdown that starts at 2 reach 0, which mac80211
> warns about. Keep the beacon skb from the page build and download that.
[...]
> @@ -1744,25 +1745,25 @@ static int rtw_download_beacon(struct rtw_dev *rtwdev)
>  		return -EINVAL;
>  	}
>  
> -	skb = rtw_get_rsvd_page_skb(hw, rsvd_pkt);
> +	/* the beacon kept by rtw_build_rsvd_page() */
> +	skb = rsvd_pkt->skb;
>  	if (!skb) {
>  		rtw_err(rtwdev, "failed to get beacon skb\n");
> -		return -ENOMEM;
> +		return -ENOENT;
>  	}
>  
>  	ret = rtw_download_drv_rsvd_page(rtwdev, skb->data, skb->len);
>  	if (ret)
>  		rtw_err(rtwdev, "failed to download drv rsvd page\n");
>  
> -	dev_kfree_skb(skb);
> -
>  	return ret;
>  }
>  
[...]
> @@ -1791,6 +1792,12 @@ int rtw_fw_download_rsvd_page(struct rtw_dev *rtwdev)
>  free:
>  	kfree(buf);
>  
> +	/* free the beacon kept by rtw_build_rsvd_page() */
> +	rsvd_pkt = list_first_entry(&rtwdev->rsvd_page_list,
> +				    struct rtw_rsvd_page, build_list);
> +	kfree_skb(rsvd_pkt->skb);
> +	rsvd_pkt->skb = NULL;
> +
>  	return ret;
>  }

This breaks hardware scan offload while an AP is active.

rtw_download_beacon() no longer fetches a beacon of its own. It reads
rsvd_pkt->skb, and rtw_fw_download_rsvd_page() clears that skb right
before it returns:

	if (rtwdev->ap_active) {
		ret = rtw_download_beacon(rtwdev);
		if (ret)
			rtw_err(rtwdev, "HW scan download beacon failed\n");
	}

rtw_hw_scan_offload() takes that branch without building a reserved page
first, so nothing repopulates the skb. Since the store has already run from
BSS_CHANGED_BEACON when the AP started, rsvd_pkt->skb is NULL by the time a
scan begins and rtw_download_beacon() returns -ENOENT:

	skb = rsvd_pkt->skb;
	if (!skb) {
		rtw_err(rtwdev, "failed to get beacon skb\n");
		return -ENOENT;
	}

rtw_ops_hw_scan() then treats the error as a failed scan and aborts it.

Before this patch the scan path worked because rtw_download_beacon() called
rtw_get_rsvd_page_skb() itself.

Could the scan path fetch its own beacon, or could the retained skb be
released only after the standalone download, with care taken to not
advance the CSA countdown twice?

Best regards,
Luka Gejak

Re: [PATCH rtw-next 1/2] wifi: rtw88: download the beacon the reserved page was built with

[Mehmet Fide]

Hi Luka,

On 2026-09-29 Luka Gejak wrote:
> This breaks hardware scan offload while an AP is active.
>
> rtw_download_beacon() no longer fetches a beacon of its own. It reads
> rsvd_pkt->skb, and rtw_fw_download_rsvd_page() clears that skb right
> before it returns:
[...]
> Could the scan path fetch its own beacon, or could the retained skb be
> released only after the standalone download, with care taken to not
> advance the CSA countdown twice?

Thanks, you are right: I checked the callers of
rtw_fw_download_rsvd_page() and missed rtw_hw_scan_offload().

v2 takes your first option. rtw_build_rsvd_page() hands the page-0
beacon skb out to rtw_fw_download_rsvd_page(), which passes it to
rtw_download_beacon() and frees it afterwards, and rtw_download_beacon()
fetches (and frees) its own beacon when it is called without one, which
is what the scan path does. So the countdown still advances once per
page update and the scan keeps its beacon.

I can only compile-test that path: the 8821C and 8822B firmware on my
dongles has no scan offload, so rtw_hw_scan_offload() is never reached
here. I will say so in the cover letter.

I will hold v2 until Ping-Ke has had a chance to look at the rest of
the series.

Best regards,
Mehmet

RE: [PATCH rtw-next 1/2] wifi: rtw88: download the beacon the reserved page was built with

[Ping-Ke Shih]

Mehmet Fide <mehmet.fide@gmail.com> wrote:
> Hi Luka,
> 
> On 2026-09-29 Luka Gejak wrote:
> > This breaks hardware scan offload while an AP is active.
> >
> > rtw_download_beacon() no longer fetches a beacon of its own. It reads
> > rsvd_pkt->skb, and rtw_fw_download_rsvd_page() clears that skb right
> > before it returns:
> [...]
> > Could the scan path fetch its own beacon, or could the retained skb be
> > released only after the standalone download, with care taken to not
> > advance the CSA countdown twice?
> 
> Thanks, you are right: I checked the callers of
> rtw_fw_download_rsvd_page() and missed rtw_hw_scan_offload().
> 
> v2 takes your first option. rtw_build_rsvd_page() hands the page-0
> beacon skb out to rtw_fw_download_rsvd_page(), which passes it to
> rtw_download_beacon() and frees it afterwards, and rtw_download_beacon()
> fetches (and frees) its own beacon when it is called without one, which
> is what the scan path does. So the countdown still advances once per
> page update and the scan keeps its beacon.

If scan request while doing channel switching, we might deny the scan
since peer (STA) might countdown itself and jump to target channel
but no beacon listened causes disconnection.

Therefore, rtw_download_beacon() fetches its own beacon without affecting
countdown (channel switch isn't operating).

Ping-Ke

Re: [PATCH rtw-next 1/2] wifi: rtw88: download the beacon the reserved page was built with

[Mehmet Fide]

Hi Ping-Ke,

On 2026-09-30 Ping-Ke Shih wrote:
> If scan request while doing channel switching, we might deny the scan
> since peer (STA) might countdown itself and jump to target channel
> but no beacon listened causes disconnection.
>
> Therefore, rtw_download_beacon() fetches its own beacon without affecting
> countdown (channel switch isn't operating).

Agreed. v2 refuses a hardware scan with -EBUSY while csa_active is set
on any interface, and rtw_download_beacon() fetches its own beacon on
the scan path, which then never runs during a countdown.

Best regards,
Mehmet

[PATCH rtw-next 2/2] wifi: rtw88: support channel switch in AP mode

[Mehmet Fide]

From: Mehmet Fide <mehmet.fide@screeningeagle.com>

hostapd's CHAN_SWITCH is refused because the driver does not announce
channel switch support, so an AP on rtw88 can only change its channel
by being torn down and started again.

Declare WIPHY_FLAG_HAS_CHANNEL_SWITCH and implement
ieee80211_ops::channel_switch_beacon the way rtw89 does: the firmware
repeats the beacon held in the reserved page, so while a switch is
announced the beacon is downloaded again every beacon interval to renew
the countdown, and ieee80211_csa_finish() is called once it completes.

Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
---
 drivers/net/wireless/realtek/rtw88/fw.c       | 29 +++++++++++++++++++
 drivers/net/wireless/realtek/rtw88/fw.h       |  1 +
 drivers/net/wireless/realtek/rtw88/mac80211.c | 14 +++++++++
 drivers/net/wireless/realtek/rtw88/main.c     |  3 +-
 drivers/net/wireless/realtek/rtw88/main.h     |  2 ++
 5 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index a4400ff51372..20f24086dd8c 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -1812,6 +1812,35 @@ void rtw_fw_update_beacon_work(struct work_struct *work)
 	mutex_unlock(&rtwdev->mutex);
 }
 
+void rtw_fw_csa_beacon_work(struct work_struct *work)
+{
+	struct rtw_vif *rtwvif = container_of(work, struct rtw_vif,
+					      csa_beacon_work.work);
+	struct ieee80211_vif *vif = rtwvif_to_vif(rtwvif);
+	struct rtw_dev *rtwdev = rtwvif->rtwdev;
+	unsigned int delay;
+
+	mutex_lock(&rtwdev->mutex);
+
+	if (rtwvif->net_type != RTW_NET_AP_MODE || !vif->bss_conf.csa_active)
+		goto out;
+
+	delay = ieee80211_tu_to_usec(vif->bss_conf.beacon_int);
+
+	if (!ieee80211_beacon_cntdwn_is_complete(vif, 0)) {
+		rtw_fw_download_rsvd_page(rtwdev);
+		rtw_send_rsvd_page_h2c(rtwdev);
+
+		ieee80211_queue_delayed_work(rtwdev->hw, &rtwvif->csa_beacon_work,
+					     usecs_to_jiffies(delay));
+	} else {
+		ieee80211_csa_finish(vif, 0);
+	}
+
+out:
+	mutex_unlock(&rtwdev->mutex);
+}
+
 static void rtw_fw_read_fifo_page(struct rtw_dev *rtwdev, u32 offset, u32 size,
 				  u32 *buf, u32 residue, u16 start_pg)
 {
diff --git a/drivers/net/wireless/realtek/rtw88/fw.h b/drivers/net/wireless/realtek/rtw88/fw.h
index 48ad9ceab6ea..0aaac8458ccd 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.h
+++ b/drivers/net/wireless/realtek/rtw88/fw.h
@@ -864,6 +864,7 @@ void rtw_add_rsvd_page_sta(struct rtw_dev *rtwdev,
 			   struct rtw_vif *rtwvif);
 int rtw_fw_download_rsvd_page(struct rtw_dev *rtwdev);
 void rtw_fw_update_beacon_work(struct work_struct *work);
+void rtw_fw_csa_beacon_work(struct work_struct *work);
 void rtw_send_rsvd_page_h2c(struct rtw_dev *rtwdev);
 int rtw_dump_drv_rsvd_page(struct rtw_dev *rtwdev,
 			   u32 offset, u32 size, u32 *buf);
diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
index 2a9b09fa76e7..915e810470aa 100644
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -164,6 +164,8 @@ static int rtw_ops_add_interface(struct ieee80211_hw *hw,
 	memset(&rtwvif->bfee, 0, sizeof(struct rtw_bfee));
 	rtw_txq_init(rtwdev, vif->txq);
 	INIT_LIST_HEAD(&rtwvif->rsvd_page_list);
+	rtwvif->rtwdev = rtwdev;
+	INIT_DELAYED_WORK(&rtwvif->csa_beacon_work, rtw_fw_csa_beacon_work);
 
 	mutex_lock(&rtwdev->mutex);
 
@@ -235,6 +237,8 @@ static void rtw_ops_remove_interface(struct ieee80211_hw *hw,
 	rtw_dbg(rtwdev, RTW_DBG_STATE, "stop vif %pM mac_id %d on port %d\n",
 		vif->addr, rtwvif->mac_id, rtwvif->port);
 
+	cancel_delayed_work_sync(&rtwvif->csa_beacon_work);
+
 	mutex_lock(&rtwdev->mutex);
 
 	rtw_leave_lps_deep(rtwdev);
@@ -556,6 +560,15 @@ static int rtw_ops_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
 	return 0;
 }
 
+static void rtw_ops_channel_switch_beacon(struct ieee80211_hw *hw,
+					  struct ieee80211_vif *vif,
+					  struct cfg80211_chan_def *chandef)
+{
+	struct rtw_vif *rtwvif = (struct rtw_vif *)vif->drv_priv;
+
+	ieee80211_queue_delayed_work(hw, &rtwvif->csa_beacon_work, 0);
+}
+
 static int rtw_ops_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
 			   struct ieee80211_vif *vif, struct ieee80211_sta *sta,
 			   struct ieee80211_key_conf *key)
@@ -973,6 +986,7 @@ const struct ieee80211_ops rtw_ops = {
 	.sta_add		= rtw_ops_sta_add,
 	.sta_remove		= rtw_ops_sta_remove,
 	.set_tim		= rtw_ops_set_tim,
+	.channel_switch_beacon	= rtw_ops_channel_switch_beacon,
 	.set_key		= rtw_ops_set_key,
 	.ampdu_action		= rtw_ops_ampdu_action,
 	.can_aggregate_in_amsdu	= rtw_ops_can_aggregate_in_amsdu,
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 0f23498b5c96..9f3da59b208f 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -2293,7 +2293,8 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
 	hw->wiphy->available_antennas_rx = hal->antenna_rx;
 
 	hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS |
-			    WIPHY_FLAG_TDLS_EXTERNAL_SETUP;
+			    WIPHY_FLAG_TDLS_EXTERNAL_SETUP |
+			    WIPHY_FLAG_HAS_CHANNEL_SWITCH;
 
 	hw->wiphy->features |= NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
 	hw->wiphy->max_scan_ssids = RTW_SCAN_MAX_SSIDS;
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index d59f6e323adf..a1974effa3d1 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -823,6 +823,7 @@ struct rtw_bf_info {
 };
 
 struct rtw_vif {
+	struct rtw_dev *rtwdev;
 	enum rtw_net_type net_type;
 	u16 aid;
 	u8 mac_id;
@@ -835,6 +836,7 @@ struct rtw_vif {
 	const struct rtw_vif_port *conf;
 	struct cfg80211_scan_request *scan_req;
 	struct ieee80211_scan_ies *scan_ies;
+	struct delayed_work csa_beacon_work;
 
 	struct rtw_traffic_stats stats;
 
-- 
2.55.0

RE: [PATCH rtw-next 2/2] wifi: rtw88: support channel switch in AP mode

[Ping-Ke Shih]

Mehmet Fide <mehmet.fide@gmail.com> wrote:
> From: Mehmet Fide <mehmet.fide@screeningeagle.com>
> 
> hostapd's CHAN_SWITCH is refused because the driver does not announce
> channel switch support, so an AP on rtw88 can only change its channel
> by being torn down and started again.
> 
> Declare WIPHY_FLAG_HAS_CHANNEL_SWITCH and implement
> ieee80211_ops::channel_switch_beacon the way rtw89 does:

No need to mention rtw89, which you have mentioned in cover letter.

> the firmware
> repeats the beacon held in the reserved page, so while a switch is
> announced the beacon is downloaded again every beacon interval to renew
> the countdown, and ieee80211_csa_finish() is called once it completes.
> 
> Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>

[...]

> diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c
> b/drivers/net/wireless/realtek/rtw88/mac80211.c
> index 2a9b09fa76e7..915e810470aa 100644
> --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
> @@ -164,6 +164,8 @@ static int rtw_ops_add_interface(struct ieee80211_hw *hw,
>         memset(&rtwvif->bfee, 0, sizeof(struct rtw_bfee));
>         rtw_txq_init(rtwdev, vif->txq);
>         INIT_LIST_HEAD(&rtwvif->rsvd_page_list);
> +       rtwvif->rtwdev = rtwdev;

Move to be first statement of this function followed by a blank line. 

> +       INIT_DELAYED_WORK(&rtwvif->csa_beacon_work, rtw_fw_csa_beacon_work);
> 
>         mutex_lock(&rtwdev->mutex);
> 

Re: [PATCH rtw-next 2/2] wifi: rtw88: support channel switch in AP mode

[Mehmet Fide]

Hi Ping-Ke,

On 2026-09-30 Ping-Ke Shih wrote:
> No need to mention rtw89, which you have mentioned in cover letter.

Dropped in v2.

> > +       rtwvif->rtwdev = rtwdev;
>
> Move to be first statement of this function followed by a blank line.

Both this and the INIT_DELAYED_WORK() are gone in v2: the work is now a
single wiphy_delayed_work in struct rtw_dev, initialised in
rtw_core_init(), so add_interface no longer touches it and a hw restart
cannot re-init an armed work.

Best regards,
Mehmet