Subject: Re: iic(4) device discovery
To: Marco Trillo <email@example.com>
From: Michael Lorenz <firstname.lastname@example.org>
Date: 10/20/2007 11:07:23
-----BEGIN PGP SIGNED MESSAGE-----
On Oct 20, 2007, at 04:42, Marco Trillo wrote:
> On 10/20/07, Jason Thorpe <email@example.com> wrote:
>> 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
>> I would much rather see a properties-based solution whereby a
>> specific callback could provide an array of devices to be direct-
> This sounds fine too. Would this be a 'prop_array_t' object being
> added to the 'struct i2c_controller' or an array member being added to
> the device properties dictionary of iic(4)?
> I think the later will be problematic, because the device list is
> controller-specific more than platform-specific, so it should be
> created and passed directly by the I2C controller (ki2c or cuda in the
> above examples).
Just to make things worse - some PMUs also have i2c buses ( we don't
support that right now but that may change any time ) and very few
have nodes for individual i2c devices.
I think a hybrid approach would be best - pass config hints via
proplib when attaching the i2cbus and let the i2c controller gather
those data either via MD callback ( for i2c controllers that aren't
100% macppc-specific, although neither cuda nor ki2c fall into this
category ) or some other ways, like model specific tables, various OF
nodes and so on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----