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
