Re: General device properties API

[Julian Coleman <jdc%coris.org.uk@localhost>]

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