# Marco Trillo 2007-10-20:
> On 10/20/07, Jachym Holecek <freza@netbsd.org> wrote:
> > This could be implemented by providing an autoconf(9) API to register
> > new cfdata entries before device discovery is started. If the arch knows
> > the list of devices and their addresses, it would simply convert firmware
> > device table into cfdata dictionaries and indirect-search iic(4) would
> > then use it transparently.
> 
> But this functionality is more controller-specific than
> architecture-specific. In the macppc example, the OpenFirmware nodes
> are ki2c(4) specific (and are in fact child nodes of the ki2c firmware
> nodes) and should not affect for example cuda(4) or pmu(4) -- and it
> should be possible to have all of these I2C controllers enabled
> without conflicts.

Ok, so ideally MD ki2c(4) should be able to tell autoconf(9) that i2cbus
instance it's about to attach has a known set of child devices. We already
have a MI way of describing "what device hangs off what with such-and-such
locators": cfdata_t objects. Converting MD notation of device hierarchy
into a cfdata_t should be trivial. So what's missing is a way for a device
(ki2c0) to register additional set of cfdata_t objects (i2c devices) that
are known to be children of some of its child (iicN) connected at given
attribute (i2cbus).

In other situations, you would inject new cfdata_t objects before
autoconfiguration is started, or during autoconfiguration from MD
device_register() hook.

This doesn't sound hard to implement and has the advantage of being
more general: this way, you could use MD device hierarchy knowledge
for any indirect-config bus (think isa(4)).

> Using the callback approach, the ki2c(4) device discover method would
> look at the child nodes of its OpenFirmware node and call a callback
> function of iic(4) to configure them. cuda(4) or pmu(4) would use a
> different implementation of the discover method.

Yes, but it works only for i2c and requires a modification to MI driver.
Other {Bus, Arch} combinations could benefit from generic solution.

	-- Jachym