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

[Mehmet Fide <mehmet.fide@gmail.com>]

Hi Ping-Ke,

On 2026-10-06 Ping-Ke Shih wrote:
> There is single one caller, so just squash into rtw_fw_csa_active().
>
> I asked to move CS work to vif, because I want to avoid this kind of
> getting vif from rsvd_pkt->rtwvif. Is there any way to avoid this?

> I'm thinking if we move back csa work to rtwdev (like v2) to avoid this kind of
> iterative.

> and avoid this iterative.

Yes. v4 puts the work back in rtw_dev, initialised once in
rtw_core_init(), and adds rtwdev->csa_vif, set when the countdown
starts and cleared when it finishes or is cancelled. rtw_fw_csa_active()
is then a test of that pointer, and the lookup through the reserved page
and both iterations are gone.

> Will it be a problem just unconditionally initializing csa work?

It was: a hardware restart replays add_interface() with the work still
armed, and initialising it again would lose the pending timer. With the
work in rtw_dev the question does not arise any more.

> As the comment, this is to download new CAM settings. If CSA is ongoning,
> you ignore the download. Then, my question is when will you download
> this properly?

The countdown work downloads the whole reserved page, which includes
the PG info page built from the current CAM, once per beacon interval
while the switch is announced, so the new settings reach the firmware
at most one beacon interval later. The same holds for the TIM update
and the download on association, which v4 skips too (Luka). The commit
message says so now.

Best regards,
Mehmet