Hi,

On 10/20/07, Jachym Holecek <freza@netbsd.org> wrote:
> # Jason Thorpe 2007-10-20:
> > On Oct 19, 2007, at 4:53 PM, Martin Husemann wrote:
> > >IMHO (but it's late at night here, this is just a quick gut feeling) a
> > >direct configured ofiic bus with tiny special attachments is the
> > >cleaner
> > >solution.
> >
> > I would much rather see a properties-based solution whereby a platform-
> > specific callback could provide an array of devices to be direct-
> > configured.
>
> 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.

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.

     -Marco