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

From: Luka Gejak

Date: Fri Oct 30 2026 - 12:19:04 EST


Hi Mehmet,

Thanks for the v9, the resume part looks good to me. One comment below.

October 26, 2026 at 4:29 PM, "Mehmet Fide" <mehmet.fide@xxxxxxxxx> wrote:

> diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> index 0f23498b5c96..48e8cad221b9 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1550,11 +1550,13 @@ void rtw_core_stop(struct rtw_dev *rtwdev)

[ ... ]

> clear_bit(RTW_FLAG_FW_RUNNING, rtwdev->flags);
> + rtwdev->csa_vif = NULL;
>
> mutex_unlock(&rtwdev->mutex);
>
> cancel_work_sync(&rtwdev->c2h_work);
> cancel_work_sync(&rtwdev->update_beacon_work);
> + cancel_delayed_work_sync(&rtwdev->csa_beacon_work);

I think there is a small window here that can leave a countdown stuck.
In the firmware recovery path this runs without the wiphy lock, so a
channel switch waiting on the mutex can get it while it is dropped here.
If its rtw_fw_csa_start() queues the work before the cancel above, the
work is cancelled but csa_vif stays set. The BSS_CHANGED_BEACON replay
after the restart then returns early, since csa_vif already matches, and
the countdown never finishes.

Maybe clear csa_vif again at the end of rtw_core_stop(), once the mutex
is taken back?

Best regards,
Luka Gejak