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

[Johannes Berg]

On Fri, 2026-02-13 at 11:11 +0100, 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 ;-)

Wait, so I wrote a lot and forgot to circle back to this question ...

Basically I think that it's not going to be useful to split it up. I
have no objections to it, but it complicates the code (especially in
hostapd) quite a bit, because it's going to be either

 1) include each thing (NPCA, DBE, ...) in its own attribute, so that
    e.g. NPCA would be 4 or 6 bytes per spec format, but then we need
    separate validation for each in nl80211

 2) we really break it all down to each individual value, so e.g. NPCA
    would have separate attributes for minimum duration threshold,
    switch and switch back delay, initial QSRC and a MOPLEN flag; this
    is a bit easier to capture in a policy, but a LOT of parameters
    overall.

The thing - and why I wrote so much - is that we basically only need a
single current, and in the case of updates additionally a single post-
update, UHR operation.

So unless we're going to completely design away from beacon templates
and create an API where including the UHR Parameters Update element is
fully the firmware's (or driver's) responsibility across all the
different frame types, then the split isn't really needed. And even if
we _do_ design it completely that way, giving the post-update UHR
operation and comparing to the pre-update one isn't a huge stretch for a
design that just required fully rebuilding all the frames (parsing all
the way into fragmented elements and putting them back together in a
completely new way, including re-fragmenting elements and subelements
etc. which all sounds very messy to me.)

johannes