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

["Luka Gejak" <luka.gejak@linux.dev>]

Hi Mehmet, Ping-Ke,

Sorry for late review, few comments below.

October 21, 2026 at 1:45 PM, "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 rtw88 AP can only change its channel by
> being torn down and started again.
> 
> Declare WIPHY_FLAG_HAS_CHANNEL_SWITCH and implement
> channel_switch_beacon: the firmware repeats the beacon held in the
> first reserved page, so while a switch is announced the page is
> downloaded again every beacon interval to advance the countdown, and
> ieee80211_csa_finish() is called once it completes. IBSS shares the
> page and the work.
> 
> The work is a delayed work of the device and csa_vif names the
> interface, both under the driver mutex. The countdown is cancelled when
> the AP stops, when the interface goes away, on WoWLAN suspend and in
> rtw_core_stop(); the BSS_CHANGED_BEACON replay after a hardware restart
> resumes it. The other page downloads during a countdown, the TIM update,
> the PG backup and the one on association, are skipped until the beacon
> after the switch, since every beacon fetch advances the countdown; the
> next download carries their changes. A scan is refused: it would take
> the AP off the channel its stations count down to.
> 
> Signed-off-by: Mehmet Fide <mehmet.fide@screeningeagle.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> ---

[ ... ]

> diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
> index 2a9b09fa76e7..182aecc76820 100644
> --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c

[ ... ]

> @@ -438,6 +443,11 @@ static void rtw_ops_bss_info_changed(struct ieee80211_hw *hw,
>               rtw_set_dtim_period(rtwdev, conf->dtim_period);
>               rtw_fw_download_rsvd_page(rtwdev);
>               rtw_send_rsvd_page_h2c(rtwdev);
> +             /* restart replay resumes it, a beacon without CSA ends it */
> +             if (conf->csa_active)
> +                     rtw_fw_csa_start(rtwdev, vif);
> +             else
> +                     rtw_fw_csa_stop(rtwdev, vif);
>       }
>
>       if (changed & BSS_CHANGED_BEACON_ENABLED) {

What happens when an IBSS is left during its countdown and joined again?

ieee80211_ibss_disconnect() leaves csa_active set and reports no
BSS_CHANGED_BEACON, so only the idle path through rtw_core_stop() clears
csa_vif. The next join reports BSS_CHANGED_BEACON with csa_active still
set and this starts a new countdown. The new beacon has no counter, so
ieee80211_beacon_cntdwn_is_complete() never returns true. The page is then
downloaded every beacon interval and scans return -EBUSY until the
interface goes down.

Would clearing csa_active in ieee80211_ibss_disconnect(), same way
ieee80211_stop_ap() does, be the right fix?

[ ... ]

> @@ -846,6 +869,7 @@ static int rtw_ops_suspend(struct ieee80211_hw *hw,
>       int ret;
>
>       mutex_lock(&rtwdev->mutex);
> +     rtw_fw_csa_stop(rtwdev, rtwdev->csa_vif);
>       ret = rtw_wow_suspend(rtwdev, wowlan);
>       if (ret)
>               rtw_err(rtwdev, "failed to suspend for wow %d\n", ret);

What restarts the countdown after a successful WoWLAN resume?

The 8822C registers rtw_iface_combs and a wowlan_stub, so an AP can be
counting down next to an associated station when the system suspends.
rtw_wow_vif_iter() only picks the station, so rtw_wow_suspend() succeeds
and mac80211 keeps the AP running with csa_active set.

rtw_ops_resume() then returns 0 and ieee80211_reconfig() skips the
replay:

        res = drv_resume(local);
        ...
        if (res == 0)
                goto wake_up;

So no BSS_CHANGED_BEACON arrives, csa_vif stays NULL and
ieee80211_csa_finish() is never called. csa_active stays set on the AP,
so ieee80211_change_beacon() and any later channel switch return -EBUSY
until the AP is restarted. Also each TIM download fetches the beacon
again, since csa_vif no longer gates it, and keeps stepping the count.

Maybe rtw_ops_resume() could restart the countdown when the AP still has
csa_active set?

Best regards,
Luka Gejak