Search Linux Wireless

Re: [DESIGN RFC] Critical Update handling in the kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/24/2025 1:48 AM, Ping-Ke Shih wrote:
> Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux