On Thu, 12 Dec 2024 at 08:36, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Tue, 2024-12-10 at 16:14 +0000, Donald Hunter wrote: > > > > + - > > + name: wlan-cipher-suites > > + type: enum > > I'm not sure exactly what this does, but I'm not sure 'enum' is the > right way to think about it. Pretty much every number (OUI + subvalue) > could be valid here, if the driver advertises support for it and you > have a supplicant that understands it. It was an attempt to enumerate the valid values, but from what you are saying I think it will need to remain as u32, probably with 'display-hint: hex". > > + - > > + name: wiphy-bands > > + attributes: > > + - > > + name: 2ghz > > + doc: 2.4 GHz ISM band > > + value: 0 > > + type: nest > > + nested-attributes: band-attrs > > + - > > + name: 5ghz > > + doc: around 5 GHz band (4.9 - 5.7 GHz) > > + type: nest > > + nested-attributes: band-attrs > > + - > > + name: 60ghz > > + doc: around 60 GHz band (58.32 - 69.12 GHz) > > + type: binary > > This (and s1g/lc) should also nest, with the same attributes? There > should be no structural difference between the bands, even if most of > the values are only used/valid for some of the bands. That makes sense. I'll add the nest type to them all. > > +operations: > > + enum-model: directional > > + list: > > + - > > + name: get-wiphy > > + doc: | > > + Get information about a wiphy or dump a list of all wiphys. Requests to dump get-wiphy > > + should unconditionally include the split-wiphy-dump flag in the request. > > + attribute-set: nl80211-attrs > > + do: > > + request: > > + value: 1 > > + attributes: > > + - wiphy > > + - wdev > > + - ifindex > > + reply: > > + value: 3 > > could the value not reference "get-wiphy" and "new-wiphy" from the > command list? That might be easier to understand? There is currently no schema or tool support for referencing enum constants when defining protocol message ids. Most of the netlink families don't have any need for an enumeration of commands in the spec; nl80211 is unusual in reporting available commands. I'm currently working on completeness of nl80211 and a couple of feature gaps in ynl-gen-c.py to resolve 'make -C tools/net/ynl' failures. I doubt that I will have a v3 patchset ready before net-next closes for the holidays. Thanks, Donald.
