[PATCH wireless-next v8 2/3] wifi: cfg80211: add initial UHR support
Harshitha Prem
harshitha.prem at oss.qualcomm.com
Wed Mar 11 22:49:00 PDT 2026
On 3/6/2026 6:13 PM, Johannes Berg wrote:
> Hi,
>
>> Thank you very much for your patience, and apologies for the delayed
>> response. We spent some time discussing this internally and wanted to
>> follow up thoughtfully.
>
> Hey, no worries, I'm clearly also not always able to respond quickly, a
> lot of things are going on at any given time ...
>
Thanks for understanding! :)
>>> This could get trickier than I imagined - you now have three periods of
>>> time:
>>>
>>> - now
>>> - after CSA but before UHR update
>>> - after UHR update
>>>
>>> and actually all three might need different UHR operation, since the CSA
>>> can change the bandwidth and therefore e.g. DBE/NPCA. The intermediate
>>> period ("after CSA but before UHR update") can be captured by the CSA
>>> operation (given a template/UHR operation for after) easily.
>>>
>>> But I was imagining we capture all this in the operations already, so I
>>> guess to do that we would need a "NL80211_CMD_MODIFY_MLD_BSS_UPDATE"
>>> command that takes the cookie and updates the post-operation values, so
>>> that the changes due to the CSA could be taken into account in the
>>> previously started UHR update.
>>
>> The idea of introducing an NL80211_CMD_MODIFY_MLD_BSS_UPDATE command
>> makes a lot of sense to us. In cases where
>> NL80211_CMD_START_MLD_BSS_UPDATE is already in progress, having a modify
>> path to update the current beacon seems easier to reason about and
>> manage. From that perspective, a pairing such as
>> NL80211_CMD_START_MLD_BSS_UPDATE together with
>> NL80211_CMD_MODIFY_MLD_BSS_UPDATE feels quite natural.
>
> Yeah, maybe, then it wouldn't ever really go to a normal SET_BEACON any
> more, maybe?
>
> I was thinking more for not having to change all the code in hostapd at
> a given time, it might be more plausible to still allow SET_BEACON and
> just keep giving the counter offsets etc., in case e.g. something "old"
> like short-preamble changes.
>
> But clearly hostapd would have to manage those offsets etc. anyway, so
> perhaps there's really not going to be any reason to support SET_BEACON
> while updates are in progress. But in that case I'd probably argue it
> (SET_BEACON) should be disallowed by the kernel, to catch errors.
Yes, that's the idea when any MLD_BSS_UPDATE is in progress, instead of
sending SET_BEACON rather use MODIFY_MLD_BSS_UPDATE.
>
>> Please find below the envisioned design flow for the UHR CU and CSA
>> intersection.
>>
>> Hostapd (User) mac80211 (Kernel) Air / Station
>> | | |
>> 1 | CMD_START_AP [Adv Notif, | |
>> | Post Notif, Upd Int] | |
>> |-------------------------->| |
>> | | |
>> 2 | CMD_START_MLD_BSS_UPDATE | |
>> | [Link:0, CurTmpl+Offset | |
>> | (All), Timer, PostTmpl | |
>> | (All), Type:UHR_CU, | |
>> | Post UHR Op element] | |
>> |-------------------------->| |
>> | | |
>> 3 | | [Set Tmpl, Timer: Adv=10, |
>> | | Post=10, TIM Update] |
>> | | |
>> 4 | Cookie X | |
>> |<--------------------------| |
>> | | |
>> 5 | EVENT_UHR_CU (CU_START) | |
>> |<--------------------------| |
>
> Not sure what the event does really, at this point? It kind of starts
> immediately anyway, no? But it also doesn't matter for this high-level
> discussion.
Yeah, it would kind of immediate, this is just an indication to user
space applications if someone is interested.
>
>> | | |
>> 6 | | Beacons: 10, 9, 8... |
>> | |-------------------------->|
>> | | |
>> 7 | [CSA Triggered: Link0, | |
>> | Count 10. Sees Cookie X] | |
>> | | |
>> 8 | CMD_START_MLD_BSS_UPDATE | |
>> | [Type:CSA, Link:0, Tmpls, | |
>> | Cookie X + Offset, | |
>> | Post Tmpl (No UHR ele)] | |
>> |-------------------------->| |
>
> Not sure I understand the "No UHR ele" part - surely the post template
> still has UHR? Or did you mean "UHR parameter update"?
>
At this point, the CSA post-beacon template would not include the
updated UHR operation element, since hostapd needs a way to determine
whether that element should be added. The updated UHR operation element
is expected to be reflected only after the advance timer expires.
In a scenario where the CSA completes before the advance timer expires,
the CSA post-beacon may not actually require the updated UHR operation
element.
Because of this, an event-driven approach was considered. For example,
if the UHR advance timer expires before the CSA completes, it could
notify hostapd, which could then update the CSA post-beacon template
with the updated UHR operation element via MODIFY_MLD_BSS_UPDATE.
> Not that there's a race here - "Sees Cookie X", but who knows the cookie
> X is even still valid?
>
> But I think we can pretty much solve that racy by marking a cookie X
> invalid in the kernel (or even FW?) and rejecting the new
> CMD_START_MLD_BSS_UPDATE operation that still refers to Cookie X -
> hostapd would just have to know about that specific rejection reason (I
> guess netlink extended status would point to the wrong cookie attr or
> so) and then rebuild the templates without taking the update with cookie
> X into account.
In this case, cookie X would still need to remain valid for a UHR
critical update, since the countdown associated with cookie X would have
to continue alongside the cookie Y (CSA) countdown. Given that, it’s not
clear whether cookie X can be invalidated at that stage without
impacting the ongoing UHR flow.
>
> But with that race aside, yeah, seems reasonable.
>
>> | | |
>> 9 | Cookie Y | |
>> |<--------------------------| |
>> | | |
>> 10 | CMD_CH_SWITCH_STARTED_ | |
>> | NOTIFY | |
>> |<--------------------------| |
>
> I don't know - this was started by CMD_START_MLD_BSS_UPDATE too, so
> probably should be some generic notification about it, or like I said
> above, maybe isn't even needed at all?
It might be possible to rely on a generic notification when this is
started via CMD_START_MLD_BSS_UPDATE. That said, since CSA has existed
for a long time, I was wondering whether also sending CH_SWITCH_NOTIFY
for backward compatibility could be considered, at least initially.
>
> (I think a good chunk of the channel switch notification is code
> unification between client and AP, does the AP even use the start
> notification?)
>
>> | | |
>> 11 | | Beacons: X=7, Y=10 |
>> | |-------------------------->|
>> | | |
>> 12 | CMD_MODIFY_MLD_BSS_UPDATE | |
>> | (Cookie X Post Tmpl w/ | |
>> | Chan Info, 3 Links) | |
>> |-------------------------->| |
>> | | |
>> 13 | | Beacons: X=1, Y=4 |
>> | |-------------------------->|
>> | | |
>> 14 | | [X=0: Modify Cur Tmpl |
>> | | w/ Post UHR Op element] |
>> | | |
>> 15 | EVENT_UHR_CU | |
>> | (CU_ADVANCE_COMPLETE) | |
>> |<--------------------------| |
>
> That should have Cookie X somehow as an attribute, of course :)
>
> Really all the events should have, but here clearly you meant X since
> the other operation isn't done yet.
Indeed, all the events should have the cookie X.
>
>> | | |
>> 16 | CMD_MODIFY_MLD_BSS_UPDATE | |
>> | (Cookie Y Post Tmpl w/ | |
>> | UHR Op + Param elements) | |
>> |-------------------------->| |
>
> What's this doing? Didn't we have post-Y templates already in the prior
> command? Otherwise isn't this quite a bit racy? Though I guess we have a
> whole beacon interval for hostapd to update everything, which really
> ought to be sufficient (though hostapd may need to stop being single-
> threaded ...)
This is mainly to allow updating the CSA post‑beacon template with the
updated UHR operation element. As you mentioned, yeah, While a full
beacon interval is available, it seemed possible that under heavier
event processing in hostapd, there could still be some short‑lived races
or inconsistencies.
>
>> | | |
>> 17 | | Beacons: X=127, Y=3 |
>> | |-------------------------->|
>> | | |
>> 18 | | Beacons: X=128/129, |
>> | | Y=2/1 (CSA done) |
>> | |-------------------------->|
>> | | |
>> 19 | | [Y=0: Set Post Tmpl |
>> | | cookie Y, UHR Param |
>> | | Off, X=130] |
>> | | |
>> 20 | CMD_CH_SWITCH_NOTIFY | |
>> |<--------------------------| |
>
> (similar comment as above wrt. what notifications are needed)
>
>> | | |
>> 21 | CMD_MLD_BSS_UPDATE_NOTIFY | |
>> | (Complete Cookie Y) | |
>> |<--------------------------| |
>
> Right.
>
>> | | |
>> 22 | CMD_MODIFY_MLD_BSS_UPDATE | |
>> | (Cookie X Post Tmpl w/ | |
>> | UpdatedChan Info) | |
>> |-------------------------->| |
>
> "X post" is a bit misleading ... it's still ongoing, because it's
> changed now but not really _after_ the update X, it's still advertising
> the update X has happened. So in some way the flow is still there.
>
> But it does point out that we need basically three (additional)
> templates for a UHR update:
>
> - announcing the upcoming update
> - announcing the update happened
> - back to normal state afterwards
>
> Which, perhaps, is indeed a bit too much to offload all to the kernel
> even in terms of the API, because if you mix another operation in (here
> in your example the channel switch Y), you end up with even more
> templates ...
That’s a fair point. With multiple operations potentially occurring in
parallel, it does seem possible that this could gradually result in an
increasing number of templates being involved.
>
> So I'm coming around to the idea that you have a notification and
> hostapd has to update the templates at that point.
Yes, that does seem to align with the direction here. This approach
would still partially rely on event‑driven updates (for example,
reacting to a UHR event) to modify the BSS via CMD_MODIFY_MLD_BSS_UPDATE
for csa. At the same time, since such notifications would likely require
the beacon templates to be updated fairly promptly, it does raise some
open questions around prioritization and handling on the hostapd side,
particularly given its single‑threaded nature.
>
>> | | |
>> 23 | | Beacons Continue... |
>> | |-------------------------->|
>> | | |
>> 24 | | Probe Request |
>> | |<--------------------------|
>> | | [Fetch TBTT] |
>> | send_mgmt (TBTT) | |
>> |<--------------------------| |
>> | | |
>> 25 | send_mgmt (Probe Resp | |
>> | w/ TBTT in UHR Param) | |
>> |-------------------------->| |
>> | | |
>
> Not sure I follow this part regarding the "TBTT" thing. Are you saying
> the RX of the probe request would have a TBTT attached to it? But does
> it matter, what matters is the TX? And that's probably impossible to get
> right?
What I was trying to describe is the handling of probe and association
responses during an ongoing UHR CU / EHT CU.
In such cases, when a probe request or association request is received,
the corresponding response may need to reflect the current countdown
state. For example, in the case of UHR, a probe response might need to
include an UHR parameters update element with the appropriate countdown
value.
The idea was that, at the time the response is being constructed, the
current countdown could be obtained from the relevant cookie and made
available to user space. This would allow hostapd to build the probe or
association response accordingly.
>
>> The diagram uses a number of abbreviations, so an explanation is
>> provided below for clarity.
>
> Oops, sorry, didn't see that before starting to reply, so maybe I missed
> something above. I'd go back and check, but I'll have to pick up my kids
> soon.
>
>> Step 14
>> The driver/firmware can update the current beacon template with
>> the post‑UHR operation element. Until the advance notification interval
>> completes, the UHR operation element would not yet be updated.
>
> Not sure I follow, are you envisioning the driver/firmware changing the
> beacon contents? I was envisioning it basically always getting the right
> template at the right time, and only filling the counters per their
> offsets.
>
>> A few potential concerns to consider:
>>
>> 1. Carrying both the current and post‑beacon templates for all
>> affiliated links of an MLD might make the NL message fairly large. we
>> are not sure how well that fits with existing practice, since multipart
>> handling seems to be used mostly for dump commands. As an alternate, can
>> we have multiple commands with message id and reassemble it?
>
> It's input into the kernel, so the size doesn't matter, I think? For
> notifications that might be an issue, and dumpit is used for data going
> _out_ of the kernel so userspace doesn't have to have arbitrarily large
> buffers ready before it knows the data, but on input I don't see how it
> matters.
Based on the earlier discussion in the below thread, I had wondered
whether there might be a potential bottleneck here.
https://lore.kernel.org/all/c7e383a9-c291-426b-a7f1-7845fabbaeeb@oss.qualcomm.com/
We will re‑check this internally to confirm whether that concern is
still applicable.
>
>> 2. There may be a small sequencing aspect worth thinking through. For
>> example, if a UHR_CU operation is close to completion and we are about
>> to apply its post‑beacon template, but before hostapd processes
>> EVENT_UHR_CU with CU_POST_NOTIF_COMPLETE it issues a
>> START_MLD_BSS_UPDATE for CSA, we could potentially end up using an
>> unexpected version of the current beacon template. This may already be
>> handled by the existing flow, but it seemed worth calling out for
>> completeness.
>
> Yes, I agree, it's something we need to think about. I mentioned that a
> bit above, perhaps one way to solve the race is to have a reject built
> in based on the cookie(s) being used, that could technically even be
> pushed all the way down to the firmware if you really wanted to.
>
> johannes
Thanks,
Harshitha
More information about the ath12k
mailing list