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. > + - > + 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. > +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? johannes
