[PATCH 2/2] i2c: Add devtree-aware iic support for PPC4xx

Grant Likely grant.likely at secretlab.ca
Tue Oct 16 14:21:38 EST 2007


On 10/15/07, David Gibson <david at gibson.dropbear.id.au> wrote:
> As the inventor of "linux,network-index", please don't invent
> "linux,i2c-index".  linux,network-index was and is a hack - it's
> badness is limited by the fact that it's essentially local to the
> bootwrapper.  It's only used in the bootwrapper, and I only really
> intended it for use in bootwrappers which provide their own device
> tree, so as to match the device nodes against whatever order the MAC
> addresses were supplied by the firmware.
>
> I plan to replace the linux,network-index thing with aliases
> (including some dtc support to make that easy) just as soon as I get
> around to it... don't hold your breath.
>
> Using a similar property from an actual kernel driver would be much
> uglier, and harder to clean up later.

This I know from first hand experience; it is Uh-gly!  :-)

>
> Using aliases would be.. less bad, but it would still require that
> the device tree always supply an alias for the iic driver to work
> which is kind of nasty.
>
> In fact I think it may be acceptle to do the idx++ thing in this
> situation.  Bus numbers are ugly, but it's not the worst ugliness in
> the horrible mess that is the Linux i2c subsystem.  It means that bus
> numbers are theoretically unstable, but that's increasingly true of
> devices of all sorts - it's up to udev to assign meaningful labels at
> the user level.

I think the real problem here comes into play when there are 2 types
of i2c busses in the system.  If they both maintain their own idx++
values; then they will conflict.  If an auto assigned bus number is
used; then it needs to be assigned by the i2c infrastructure; not by
the driver.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195



More information about the Linuxppc-dev mailing list