[DESIGN RFC] Critical Update handling in the kernel

[Manish Dharanenthiran]

On 10/3/2025 8:58 AM, Ping-Ke Shih wrote:
> Nicolas Escande <nico.escande at gmail.com> wrote:
>> On Thu Sep 4, 2025 at 4:24 PM CEST, Jeff Johnson wrote:
>>> On 7/24/2025 1:48 AM, Ping-Ke Shih wrote:
>>>> Johannes Berg <johannes at sipsolutions.net> wrote:
>>>>>> Before we move forward with implementation, we'd like to confirm whether
>>>>>> the proposed design looks sound. Are there any concerns or potential issues
>>>>>> we should be aware of?
>>>>>>
>>>>>> Out of curiosity, we're also interested in understanding how other vendors
>>>>>> are currently handling this feature in their downstream drivers. Is it
>>>>>> typically offloaded to firmware, or is the logic implemented in the kernel?
>>>>>> Just want to confirm whether all this will be used only by mac80211_hwsim
>>>>>> or will there be any actual users?
>>>>>
>>>>> I think Ping-Ke previously indicated that they were planning to do
>>>>> things host side? I'm not super familiar with the timing constraints
>>>>> though, so I'm not sure what that might imply.
>>>>
>>>> Yes, Realtek vendor driver handles the feature in host driver. Having not
>>>> tested CSA and ML procedure mentioned in this discussion thread, we
>>>> are also not sure how timing constraint to evaluate if we have to implement
>>>> the feature in firmware.
>>>
>>> Ping-Ke (and Johannes),
>>> Have you had a chance to review Aditya's August 21 follow-up?
>>>
>>> We'd like to move forward with our firmware-based approach (since that logic
>>> is already shipping in our OpenWrt-based systems). Perhaps Realtek can propose
>>> alternative host-based logic, and there can be a flag to select either
>>> host-based or firmware-based Critical Update handling?
>>>
>>> Thanks,
>>> /jeff
>>
>> Hey guys, any news on this one ? Seeing the ieee802.11 bn preliminary work done
>> by Johannes, reminded me that there are still some usefull parts of 802.11 be
>> that are not completely finished yet ...
>>
>> Thanks,
> 
> Sorry for the late. I checked with Realtek vendor driver, a cfg80211-based
> driver, which prepares CSA IE across links by driver, and send firmware
> beacon content with offset of countdown of CSA IE. Then firmware will countdown
> and inform driver when countdown becomes zero.
> 
> This info is still not very useful to decide where it should be implemented though.
> 
> 

Thanks all for your inputs and suggestions. After internal discussions, 
we have decided to proceed with the hostapd-based approach for updating 
beacons in the non-offloaded model. Once we have a basic working 
implementation of this design, we will share it for review.

Regards
Manish Dharanenthiran