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

[Segher Boessenkool <segher@kernel.crashing.org>]

>>> Aliases can also provide a reasonable way of enumerating devices, if
>>> "reg" isn't suitable on its own.
>>
>> Yes.  In almost all cases, drivers and subsystems do not need this at
>> all though.  In OF, one device points to another by putting the 
>> phandle
>> of that pointed-to device in some property (and buses are represented
>> by their parent bridge).  If the Linux subsystem wants to use an 
>> integer
>> for distinguishing between its various buses, that's fine, but it can
>> just make up these numbers -- the numbers themselves have no actual
>> meaning, only the relationships expressed via those numbers do.
>
> That's true.  However if all the system documentation uses a
> particular numbering of the devices, it's convenient if we can use the
> same numbering in Linux.

Sure, it's convenient, and you can use aliases to get the naming you
want accessible to the user.  The drivers shouldn't depend on this
naming internally though, esp. since it doesn't really help anything.

> Incidentally, another word on "cell-index".  Even for its intended
> purpose, this was always a compromise.  The strictly correct way to
> handle shared registers like this is for the node representing the
> shared resource to have a table of phandles pointing back to the
> devices controlled by the shared registers from which the appropriate
> indices can derived.

IMO, there is no really good (let alone "correct") way of handling
this.

> On at least some 4xx chips, however, the shared resources are
> scattered around various places, but all use the same device
> numbering.  Therefore it seemed expedient to encode that numbering in
> a single place - 'cell-index' - rather than having several such
> tables.

Yeah, it seems to work out for those 4xx.  Other platforms would be
well advised to consider the tradeoff for themselves though, many
SoCs have an even more "wild" design than 4xx does ;-)


Segher