Re: Overhaul of I2C and SPI device autoconfiguration

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sat, 11 Sep 2021 15:43:24 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> For a few months now, I've been working on improving the auto
> configuration of I2C and SPI devices.  These busses, of course, are
> not self-enumerating, and besides indirect configuration of devices
> listed in a kernel config file, enumerating based on information in
> platform config data (e.g. Devicetree, OpenFirmware, ACPI) was
> supported by having controller drivers explicitly call
> OpenFirmrware, FDT, or ACPI-specific code to populate a dictionary.
> Yuck.
> 
> My new mechanism instead uses the platform config data to enumerate
> the devices directly, without having to get a dictionary involved at
> all.  It also provides a tidier mechanism to pass device handles to
> each driver via the normal mechanism, rather than using the
> i2c_attch_args::ia_cookie / i2c_attch_args::ia_cookietype hack.

I'm struggling to understand the problem that this overhaul solves,
and it looks like there's a lot of different changes going on here.

I'm going to focus on what I think is the crux of the changes, but if
I've missed something please fill me in -- I'm trying to figure out a
clear statement of what the problem is and why the change solves the
problem, but I'm getting lost in all the mechanism of how you're doing
it.

Right now, the way it works is:

1. platform-specific bus (e.g., dwiic_acpi.c, fdt_i2c.c) creates a
   table of devices (e.g., i2c) from platform data, stored as a
   proplib dictionary (which is untyped, has no typo detection, &c.)
   passed through i2cbus_attach_args

   (Sometimes the data table is passed via the parent device's
   i2c-child-devices property, but from a sampling of users it's not
   clear to me why anything uses that instead of just passing it in
   i2cbus_attach_args.)

2. iic_attach pulls the dictionary out of i2cbus_attach_args and does
   config_found for each entry in it to attach i2c devices

The way it works in your change is:

1. platform-specific bus has an enumeration procedure, passed through
   a device's device handle device_call vtable

2. iic_attach pulls the enumeration procedure out of device_handle and
   passes a callback that does config_found to attach i2c devices

So the primary differences are:

- passing data table vs enumeration procedure from platform to iic(9)
- using proplib in i2cbus_attach_args vs device_call in device_handle

These are differences, but why?  What does restructuring it this way
buy us?

(I do see a problem with the proplib part: it's untyped and has no
typo detection.  We could fix that by using a typed struct/array in
i2cbus_attach_args instead of a proplib dictionary.)


Let's suppose as a premise that enumeration-procedure is better than
data-table for some reason (I don't know what that reason is yet, but
maybe you can explain).  Why not just pass the enumeration procedure
into i2cbus_attach_args instead of the data table as we do now?  What
does going through a device_handle, and through the indirection of
novel runtime method dispatch logic in device_call, buy us?