On Wed, 11 Mar 2026 16:30:03 +0100 Andrew Lunn wrote: > > I like this. The nice thing is that since "name" is a string, we're not > > locked into an enum -- drivers report what they have using 802.3 > > vocabulary, and we document the recommended names (pcs, pma, pmd, mii) > > with references? That way it's unambiguous, but not too constrained. > > It is both good and bad. I expect some vendors will just ignore the > text and use what their data sheet says, because they don't know > better. An enum forces more consistency.
enum only enforces using a value from a fixed set. The uAPI itself cannot enforce functional equivalence. Worst case this may result in different vendors interpreting the enum differently. With a string there's a better chance that even if not matching between the vendors at least a user with a databook in hand will know exactly what the Linux API will do. Could someone please explain to me what the use case for standardization of the enum values would be? I push hard for standardization of stats, because with standard stats its easy to build high level standard tools. I don't understand what value standardization across vendors what the last step of the MAC is called brings us. Please explain, and if we have a real use case in mind it should be possible to write a selftest that verifies that use case is met by any given device. Which reminds me -- I was suggesting that we add an order / id to the stages, not just name. Because AFAIU being able to request the loopback "very last loopback point of MAC" or "first loopback point of PHY" is something that should be doable without user having to parse the names / enums and understanding them.
