[DESIGN RFC] Critical Update handling in the kernel

Jeff Johnson jeff.johnson at oss.qualcomm.com
Thu Sep 4 07:24:24 PDT 2025


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




More information about the ath12k mailing list