On 10/15/07, David Gibson <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
