[PATCH wireless-next v8 2/3] wifi: cfg80211: add initial UHR support
Harshitha Prem
harshitha.prem at oss.qualcomm.com
Tue Feb 24 03:01:47 PST 2026
On 2/17/2026 3:35 PM, Johannes Berg wrote:
Hi Johannes,
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.
> Hi,
>
>> 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.
>
> Well, so honestly, you should probably treat what I write as equivalent
> to a paper napkin sketch during a night of drinking ;-)
>
> I surely didn't think it totally through. I was just trying to
> illustrate that I feel like we need to have some kind of new design for
> all these overlapping updates (CSA, BSS color change, EHT and UHR
> critical updates?) than the piecemeal design we have now.
>
> And, importantly, that perhaps I think that this means we need to have
> "post-update UHR operation" more than the individual UHR operation
> updates broken out - which after all is where we started from.
>
>
>> 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.
>
> Don't know if timers would be really in mac80211 - I guess if the driver
> pulls each individual beacon then mac80211 could handle the countdown,
> but otherwise this might just be given to firmware.
Yes, agreed.
>
> Also I guess the counter would have offset(s) from the start, i.e. the
> beacon template would be in this operation already. Or maybe even beacon
> updates for multiple links? Don't know if that really matters much
> either way.
>
>> 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().
>
> Sort of, yeah. I imagined that the CMD_UPDATE_AP would come with a list
> of "cookie X: { offset X_1, offset X_2 }, cookie Y: { offset Y_1 }" or
> something like that.
>
>> 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.
>
> Would have to, I think? I think in your example it's unlikely the _after
> CSA_ template still has cookie X / offset(s) X_n, since you only had 10
> beacon intervals overall for the UHR critical update and CSA might be
> longer, but we could also imagine the UHR critical update was advertised
> for a longer time.
>
>> 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.
>
> 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.
>
> FWIW, I was also kind of imagining that we'd design this combined update
> command in a way that it replaces the CSA and color change commands,
> handles the proposed link removal thing from Lorenzo, and then we don't
> need to handle overlapping operations of all kinds, just of this new
> kind that can do many different things. Not a huge difference though
> since CSA/CCA would map to a subset of the new "thing".
>
[...]
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) | |
|<--------------------------| |
| | |
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)] | |
|-------------------------->| |
| | |
9 | Cookie Y | |
|<--------------------------| |
| | |
10 | CMD_CH_SWITCH_STARTED_ | |
| NOTIFY | |
|<--------------------------| |
| | |
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) | |
|<--------------------------| |
| | |
16 | CMD_MODIFY_MLD_BSS_UPDATE | |
| (Cookie Y Post Tmpl w/ | |
| UHR Op + Param elements) | |
|-------------------------->| |
| | |
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 | |
|<--------------------------| |
| | |
21 | CMD_MLD_BSS_UPDATE_NOTIFY | |
| (Complete Cookie Y) | |
|<--------------------------| |
| | |
22 | CMD_MODIFY_MLD_BSS_UPDATE | |
| (Cookie X Post Tmpl w/ | |
| UpdatedChan Info) | |
|-------------------------->| |
| | |
23 | | Beacons Continue... |
| |-------------------------->|
| | |
24 | | Probe Request |
| |<--------------------------|
| | [Fetch TBTT] |
| send_mgmt (TBTT) | |
|<--------------------------| |
| | |
25 | send_mgmt (Probe Resp | |
| w/ TBTT in UHR Param) | |
|-------------------------->| |
| | |
26 | | [Post Notif Complete: |
| | Set Post Tmpl Cookie X] |
| | |
27 | EVENT_UHR_CU | |
| (CU_POST_NOTIF_COMPLETE) | |
|<--------------------------| |
| | |
28 | | [Continue w/ Updated TIM] |
| | |
29 | EVENT_UHR_CU | |
| (CU_SESSION_END) | |
|<--------------------------| |
| | |
The diagram uses a number of abbreviations, so an explanation is
provided below for clarity.
Step 2 – NL80211_CMD_START_MLD_BSS_UPDATE
This would include:
1. The affected link ID
2. Current beacon templates for all links, along with the offsets
where counters need to be updated.
3. Post‑beacon templates for all links
4. The post‑UHR operation element
5. Countdown values
6. Type: UHR CU
Step 8 – NL80211_CMD_START_MLD_BSS_UPDATE
This would include:
1. The affected link ID
2. Current beacon templates for all links, along with
the offsets where counters need to be updated
3. Cookie X – { offset_A }
4. Post‑beacon templates for all links
5. Countdown values
6. Type: CSA
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.
Step 12 & Step 22
These steps are somewhat duplicate, but keeping the latest modified
state once hostapd receives NL80211_CMD_MLD_BSS_UPDATE_NOTIFY_COMPLETE
seems reasonable.
Step 24
Reporting the TBTT count back to hostapd for attribute types such as
UHR_CU, LINK_REMOVE, etc.
Cookies act as identifiers for both the post‑beacon template and the
associated countdown values.
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?
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.
Thanks,
Harshitha
>
> Thanks,
> johannes
More information about the ath12k
mailing list