Hi all,

The current iic(4) framework does not provide any means of automatic
device discovery from the I2C controller. It simply calls
config_search() to probe all the in-config-file devices with its
configured addresses.

The problem is that the probe()/match() function of an I2C device
can't do a very good decision. It can test if it can talk to a device
at its configured address or something like that, but this can be
problematic, and since a I2C address is only 7-bit length, it can
cause conflicts.
And because of this, the config file needs to have the addresses of
the I2C devices hardcoded (the 'addr' parameter), to have something to
'probe'.

But in some architectures, the firmware provides a list of the devices
present in the I2C bus. One example is macppc OpenFirmware. It
provides the address and also a 'name' and 'compatible' properties
which identify the device.

In fact, this device discovery is already done in the MD drivers, with
specific attachments for each device. One example from macppc config
file:

ki2c* at obio?
iic* at ki2c?
adt7467c* at ki2c? # specific attachment

If the MI iic(4) framework supports device discovery, there would be
no need for the specific ki2c attachment:

ki2c* at obio?
iic* at ki2c?
adt7467c* at iic? addr ? # generic attachment

The 'addr' parameter could also be wildcarded since its provided by
the firmware.

This can also allow to remove ugly conflicts, like in this example
also from macppc config file:

iic0 at cuda0
sgsmix0 at iic0 addr 0x8a # specific attachment

The "sgsmix" device needs to be hardcoded to "iic0" at cuda0. If you
use "iic?" instead, a bogus sgsmix device will attach to "iic at ki2c"
even though no sgsmix device is connected at ki2c.
(This also causes the first iic device be "iic1" instead of "iic0" if
no cuda is present, which is ugly.)

With iic(4) supporting device discovery, this could be changed to:

iic* at cuda?
sgsmix* at iic? addr ? # generic attachment

There would be no conflict, since the ki2c discovery implementation
will not present an sgsmix device -- the cuda driver will do it, and
provide its address too (no need to hardcode it).

I have some patches that implement this, it's actually quite simple.
The changes would be as follows:

 o Add an optional 'ic_discover' method to 'struct i2c_controller'. An
I2C controller can provide an implementation which discovers the
available devices (most likely from firmware-supplied data) and calls
the appropriate functions to configure them.
If no implementation is supplied, the config_search() method is used.

 o Add an optional 'ia_name' member to 'struct i2c_attach_args'. If
this is not NULL, an I2C device driver can compare this to a list of
known strings with the models it supports.
This name will be filled by the discover function if available. If no
discovery is done, this will be NULL.


What do you think?


   -Marco