Re: General device properties API
> On Aug 16, 2021, at 9:11 AM, Michael van Elst wrote: > > On Mon, Aug 16, 2021 at 06:46:17AM -0700, Jason Thorpe wrote: >> >>> On Aug 16, 2021, at 2:31 AM, Michael van Elst wrote: >>> Isn't that what we do today? Have a common name and value format, >>> copied/translated from various sources and stored in the MI device >>> dictionary. >> >> We sort of have it, and it?s a dumpster fire which is why I want to get away >> from that. It doesn?t scale (a new driver that needs a new property suddenly >> needs a new hook in MD code? Yiuck?), and it?s wasteful in terms of memory >> consumed. > > > I'd say querying all possible MD sources in each driver scales less > and it gets worse when you want to report such properties in some > coherent way. Luckily for us, that isn't necessary because (a) an operating system way more popular than NetBSD has already defined the standard for recent and future hardware, (b) other firmware platforms have essentially embraced that standard due to that juggernaut, and (c) for legacy systems, the new standard maps pretty easily to the old conventions with only a few minor variances that can be handled on a case-by-case basis. So, and please bear with my radical idea here, maybe we could just roll with that standard and have the ability to interact with it in a more-or-less native way (and without additional memory consumption) rather than insisting on a translation layer that gratuitously changes the spellings of the property names and requires us to know about each one ante tempus? -- thorpej
Re: General device properties API
On Mon, Aug 16, 2021 at 06:46:17AM -0700, Jason Thorpe wrote: > > > On Aug 16, 2021, at 2:31 AM, Michael van Elst wrote: > > Isn't that what we do today? Have a common name and value format, > > copied/translated from various sources and stored in the MI device > > dictionary. > > We sort of have it, and it?s a dumpster fire which is why I want to get away > from that. It doesn?t scale (a new driver that needs a new property suddenly > needs a new hook in MD code? Yiuck?), and it?s wasteful in terms of memory > consumed. I'd say querying all possible MD sources in each driver scales less and it gets worse when you want to report such properties in some coherent way. You can only win if you reduce this to abstract properties (easily stored in the device dictionary) and let MI code work on these. And drivers should share such abstractions where possible. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: General device properties API
> On Aug 16, 2021, at 2:31 AM, Michael van Elst wrote: > > j...@coris.org.uk (Julian Coleman) writes: > >> We can decide on the name that we'll use (e.g. `ethernet_address') and >> use that in all the drivers. > > Isn't that what we do today? Have a common name and value format, > copied/translated from various sources and stored in the MI device > dictionary. We sort of have it, and it’s a dumpster fire which is why I want to get away from that. It doesn’t scale (a new driver that needs a new property suddenly needs a new hook in MD code? Yiuck…), and it’s wasteful in terms of memory consumed. -- thorpej
Re: General device properties API
j...@coris.org.uk (Julian Coleman) writes: >We can decide on the name that we'll use (e.g. `ethernet_address') and >use that in all the drivers. Isn't that what we do today? Have a common name and value format, copied/translated from various sources and stored in the MI device dictionary.
Re: General device properties API
Hi, > How do I know what properties are going to be available in a driver? > Is it part of an internal kernel<->kernel interface like device > properties, or just whatever is passed through the OF/FDT or ACPI > firmware? I think that we need a standard form for each type of information. The source would be the firmware, but MI code is responsible for converting that into the standard form for drivers to use. > If the latter, what happens if I want to use the same driver on a > system that might use OF/FDT or ACPI, where OF/FDT or ACPI provide the > same information by different spellings like `mac-address' vs > `ethernet-address' (hypothetical)? Or is this intended only for > drivers where the binding to a particular type of firmware device tree > is baked into the driver, so this kind of thing won't ever come up? We can decide on the name that we'll use (e.g. `ethernet_address') and use that in all the drivers. The driver might also need to query other properties, so there will have to be co-ordination between the code that reads the firmware (which properties to store?) and the device driver. An example might be GPIO's, which have a large number of hardware uses. We'll want to be able to read or overlay information about the pins from the firmware, and then to setup other subsystems from the driver, based on the information provided. A temporary solution is: https://nxr.netbsd.org/xref/src/sys/arch/sparc64/sparc64/ofw_patch.c#130 https://nxr.netbsd.org/xref/src/sys/dev/i2c/pcf8574.c#176 where I encoded information about the pins and (later in the device driver) attach sysmon or led. This should be done in a better (standardised) way because we need to do similar on other hardware. Again, there isn't a common way across hardware, so we'll have to make our own. Regards, Julian
