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

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

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@gmail.com> 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