[DESIGN RFC] Critical Update handling in the kernel

[Nicolas Escande]

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,