Re: [PATCH net v3] wifi: nl80211: document sta-info nested attribute

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 02 Oct 2026 19:34:19 +0200 Johannes Berg wrote:
> On Sat, 2026-09-05 at 09:46 +0200, Johannes Berg wrote:
> > On Mon, 2026-08-17 at 08:47 -0700, Jakub Kicinski wrote:  
>  [...]  
> > > 
> > > Hi Johannes! Should we add this file to wireless in MAINTAINERS?
> > > Or do you prefer for us to handle the YAML stuff directly?  
> > 
> > Not sure, we don't really seem to be using it for all I know, and so
> > it's just been getting some random updates like this, I guess.
> > 
> > I think I tend to prefer the status quo, but I guess I could also just
> > apply patches to it if you prefer.  
> 
> So that's what I said a month ago, but because Jouni prodded me about
> our inconsistent documentation today, I actually looked at converting
> *all* of nl80211.h and our hand-rolled policies to be generated.
> 
> It ... takes some work, and ends up being 12k (!) lines of yaml, vs.
> today's 7.2k of nl80211.h and ~1k policy in nl80211.c.
> 
> It also requires a bunch of changes to the tooling:
> 
>  - kdoc comments for attribute-set enums
>  - exact-len-warn check
>  - validate-fn check support and creating their prototypes
>  - combining min-len/max-len for binary attributes
>  - strict-start-type support
>  - flag to generate the whole attrs without linking them from ops
>    (otherwise we get even many many more lines of yaml)
>  - NLA_NESTED/indexed arrays support
>  - allow nesting the global policy into itself (yeah ... I want some of
>    what we were smoking ;-) )
>  - allowing inheriting different members for kernel policy side
>  - drop nesting when subset overrides type ... not even sure how to
>    explain this right now
>  - option to define only policy, not ops
>  - allow taking ops IDs from an enum, because our ops don't match the
>    ynl ops too well
>  - enum-max-name for definitions to adjust naming
> 
> There's a license issue - we have ISC license on nl80211.h now, but
> Donald and Hilal picked GPL/syscall/BSD-3 for the yaml and of course

That license is required for all netlink specs, FWIW
It's totally my fault if it's wrong, I just didn't want it to be
_just_ GPL since that would propagate to use space code which
we want to be permissive about. The spec is effectively a uAPI
description it should be public domain in my non-layer mind.

> that carries over to the generated .h file, not sure if that's an issue
> for downstream projects but might be with advertising clause? Could we
> change it if I'm adding >10k new lines from nl80211.h? :)
> 
> I can post it but ... is it worth it? Not even sure it would
> significantly simplify our lives, although the generated header file
> with documentation is much more regular in that it always has the type,
> etc. (which is what Jouni was asking about)

Well, I certainly don't care so my choice would be not to have to review
the code gen changes (: