[PATCH wireless-next v8 2/3] wifi: cfg80211: add initial UHR support

[Harshitha Prem]

On 2/13/2026 3:41 PM, Johannes Berg wrote:
> Hi Harshita,
> 
>>> Should we add a separate netlink attribute for the UHR operation, which
>>> hostapd would fill with the _full_ data like it appears in association
>>> response etc.?
>>>
>>> That way, hostapd doesn't need to build a separate data/attribute
>>> structure but can just use hostapd_eid_uhr_operation(..., false) for it.
>>>
>>> An alternative would be to add more attributes for everything, but it's
>>> probably more complicated on both sides?
> 
>> Thank you for the suggestions.
>>
>> We feel that using separate nested attributes for each feature is the better approach, as this allows us to reuse the attributes for the Enhanced BSS Parameter Critical Update procedure, where similar information is carried in the UHR parameters update element.
> 
> Heh, I'll admit I'm surprised - I'm usually the one advocating for
> finer-grained attributes, and here I didn't ;-)
> 
>> While this approach is slightly more verbose, we believe it offers better extensibility for the future.
> 
> Does it actually, though?
> 
> I had sort of expected hostapd to add the UHR Parameters Update element
> to the beacons, and configure some way of having firmware set the
> countdown ("Countdown Timer"). Turns out this is not only in beacons but
> also in probe response, (re)association response and (UHR? [1]) link
> reconfiguration response frames.
> 
> [1] the spec says "Link Reconfiguration Response" but I think it should
> say "UHR Link Reconfiguration Response"
> 
> But I guess this is going to end up a continuation of the previous wifi7
> discussion from last year [2] which hadn't really completed. And Lorenzo
> just posted another thing on this [3].
> 
> [2] https://lore.kernel.org/linux-wireless/20250717045540.27208-1-aditya.kumar.singh@oss.qualcomm.com/
> [3] https://lore.kernel.org/linux-wireless/20260212-mt7996-link-reconf-v1-0-2b110340d6c4@kernel.org/
> 
> 
> So I think maybe we need to figure out how we will do all of this first?
> 
> Naively, I would've said ... something stupid. I'm reading the spec as
> I'm writing this ;-) The UHR Parameters Update element is actually
> included in all the beacons across the entire AP MLD.
> 
> Maybe we need to take a step back from our previous discussion as well,
> and introduce a broader concept here?
> 
> 
> I could imagine, for example, something where you say in the nl80211 API
> some variation of
> 
>  1) Let's start a new update operation ("NL80211_CMD_START_MLD_BSS_UPDATE"),
>     I guess already with some parameters saying:
>      - the updated affiliated AP (link)
>      - the number of beacon intervals you want to do it for
>      - the post-update UHR operation (?)
>        (or the new channel if it's CSA? etc.?)
> 
>      - maybe - more critical if we use it for CSA - already the beacon
>        templates for all the links? with all the things I say in (2)
>        below, but that's more complex maybe?
> 
>        the reason I say this is that there's a difference here in how
>        the counter is done - for CSA etc. the things have to disappear
>        from the beacon immediately, for UHR updates they stick around
>        and the counter indicates "in the past"
> 
>     returning a cookie for the operation.
> 
>  2) hostapd updates each link's beacon now including the UHR Parameters
>     Update element(s), for each currently ongoing update it includes -
>     indexed by the cookie - a list of offsets where the counters are
>     updated.
> 
>     Thing is that this depends on the operation - CSA will already need
>     the post-switch beacon template so the flow can continue without
>     involving hostapd, hostapd may however need to update the beacon in
>     the interim (both pre- and post-switch ones!) and need to refer
>     again to where the counters are filled in ...
> 
> 


Hi Johannes,

This approach looks well suited to handling overlapping update scenarios.

To make sure I understand it correctly, I’d like to walk through a
concise example where a UHR critical update and a CSA overlap on link 0
of a 3‑link AP MLD.


t1: A UHR critical update is triggered. hostapd sends
NL80211_CMD_START_MLD_BSS_UPDATE with an advanced notification (5
TBTTs), post‑interval (5 TBTTs), and the beacon template with UHR
parameters update element for link 0. Timers start in mac80211, and
hostapd receives cookie X.


t2: hostapd sends NL80211_CMD_UPDATE_AP with cookie X and offset where
the counter is updated for link 1 (and then link 2).

the countdown values would be handled in mac80211 with the offset
mentioned similar to ieee80211_set_beacon_cntdwn().

t3: Before the UHR advanced interval completes, a CSA is triggered (due
to radar or user‑initiated). Another NL80211_CMD_START_MLD_BSS_UPDATE is
issued with CSA countdown 5, including CSA and after beacon templates.
The after template carries cookie X and the offset. Since UHR CU is
already in progress, hostapd could also include an updated parameters
update element. Also, an updated UHR operation element which can be
modified in after beacon template if CSA finishes after the UHR CU
advance interval. (why to provide the UHR operation element separately
is because the advance notification can be before or after the CSA
finalize).
hostapd then receives cookie Y for the CSA.


t4: hostapd issues NL80211_CMD_UPDATE_AP for link 1 with cookie X (UHR
offset) and cookie Y (CSA offset), followed by link 2.


t5: When the UHR advanced notification interval expires, the CSA after
beacon template is updated to reflect the new operation element by
mac80211 or getting it from hostapd.


t6: Once the CSA completes, the driver updates the after beacon template
along with updated counter for UHR parameter update element. (since it
will be in the post notification interval)


t7: When the UHR post‑interval completes, the UHR parameter update
element is removed. Since offsets are known, the driver can remove it
from the latest beacon template.

Please let me know if this sequence aligns with the intended behavior,
or if I’m missing any edge cases.

Also, CSA during NPCA parameter update seems very tricky as the channel
information advertised in NPCA may not be relevant when there is a CSA,
perhaps stop the NPCA CU (still spec has not mentioned any details on
the abort scenario though)

Even, in case of link removal during UHR CU update, we need to stop the
UHR CU.

Furthermore, the UHR capabilities carries the advance notification
interval, post notification  (i guess yet to be added in element as I
see it in "37-8—Enhanced Critical Updates Mechanism") and update
indication in TIM interval, these intervals can be sent in the START_AP.
I assume, these intervals cannot be modified dynamically as these are
exchanged in assoc response (Will reconfirm again).

For beacon offloaded drivers, NL80211_CMD_START_MLD_BSS_UPDATE can be as
a trigger. May be we can add the updated UHR operation element in case
of UHR. So, that firmware/driver handle the timers as well as
constructing the elements since "the encoding of fields in Mode specific
parameters for any feature say DPS/NPCA/DBE etc.. is same as the
corresponding field in operation parameters field for that feature" (but
i see bit variations for NPCA between both)

I guess, this means the proposal of having a separate netlink attribute
for the UHR operation with _full_ data like is much useful.

Still, we are thinking through on all the other cases of wifi-7/CCA etc..

> Either way, it feels like we've reached the end of where the current
> design with CSA and BSS color updates will take us. Lorenzo already gave
> up and put the parsing into the driver to find the offsets, but I
> personally think that's very inflexible.
> 
> Some operations such as link removal may not need to have perfect
> timing, but some others like CSA really do want the updates to happen at
> the precise moment.
> 
> In some way, it's almost good that we haven't completed the WiFi7 part
> since the UHR part throws another curveball with the counters
> decrementing below zero - for past updates - in a sense.
> 
> 
> johannes

Thanks in advance for your time and clarification.

Regards,
Harshitha