quoted

quoted

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