Re: [PATCH rtw-next v5 2/3] wifi: rtw88: update the beacon from a wiphy work

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

Hi Ping-Ke,

On 2026-10-12 Ping-Ke Shih wrote:
> What "mac80211 state" did you mean? Without wiphy_work, it can't state
> it?

bss_conf.csa_active: patch 3 gates the TIM download of this work on it,
and mac80211 writes it under the wiphy lock. That was the only reason
for the wiphy work; the work needs nothing else from mac80211.

> rtw88 doesn't use wiphy work/lock yet. and you are the first one to use
> wiphy_work. Mixing to use wiphy work/lock and ieee80211_work with driver
> lock looks not good. Should we just use ieee80211_work to avoid confusing?
>
> Or we should migrate to wiphy work/lock?
>
> For me, I prefer you use ieee80211_work with driver lock for now, because
> I guess I don't have time to verify the migration...

Agreed, v6 does that and this patch goes away: update_beacon_work stays
as it is, cancelled in rtw_core_stop(). The countdown work of patch 3
becomes an ieee80211 delayed work under the driver mutex as well, and
the gate in the TIM download reads the driver's own csa_vif under the
mutex instead of mac80211's csa_active, so no wiphy lock is needed
anywhere in rtw88. The countdown work still reads csa_active once per
beacon interval as its exit condition, a plain read like mt76 does in
its beacon path.

> Or you should add wiphy lock on IPS path, and cancel the work.

Not needed once both works are regular ones: rtw_core_stop() cancels
them, and the IPS path and the firmware recovery both go through it.

Mehmet