Re: "cell-index" vs. "index" vs. no index in I2C device nodes

["Grant Likely" <grant.likely@secretlab.ca>]

On Fri, Jun 6, 2008 at 12:21 AM, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Ben,
>
> On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote:
>> > As far as I am concerned, it's really up to the maintainers and users
>> > of this platform. All I am asking for is that you do not call
>> > i2c_add_numbered_adapter() on an adapter with an automatically
>> > generated number. This function must only be used for adapter's those
>> > number is well defined. If an adapter doesn't have a well-defined
>> > number then use i2c_add_adapter() (but then you can no longer declare
>> > your I2C devices as part of the platform data.)
>>
>> Can't we just give those things -names- instead of numbers ?
>
> Good question. These i2c adapters already have names
> (i2c_adapter.name), which are set by their respective drivers with more
> or less grace depending on the driver [1]. What we don't have though is
> the possibility to instantiate i2c devices by adapter name.
>
> We could certainly add a busname field to struct i2c_devinfo and
> implement i2c_register_board_info_by_name() if it seems to be worth the
> extra code and memory. I am open to the idea if it solves a problem
> with no other clean solution.

Even this isn't necessary.  In arch/powerpc we don't really need to
register the board info separately from the bus driver so we don't
need to jump through hoops to match a board_info with an i2c bus.  The
device tree data structure already links the i2c devices with the bus
they are on, so an OF-aware i2c bus driver will match against a node
in the device tree and then use all the child nodes to register i2c
devices against itself.

This, of course, only applies to platform level i2c busses described
in the device tree.  Plugin devices like PCI cards still can create
their own i2c busses in the usual way.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.