[RFC] MPIC Bindings and Bindings for AMP Systems

[Blanchard, Hollis]

On 01/07/2011 08:44 AM, Grant Likely wrote:
> On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis
> <Hollis_Blanchard at mentor.com>  wrote:
>> On 01/07/2011 07:48 AM, Grant Likely wrote:
>>> Actually, for a while now the kernel has been moving towards userspace
>>> being responsible for device identification.  That's what udev is for.
>>>    The kernel udev looks at the available information when a device is
>>> registered/bound, and it creates useful symlinks to the dynamically
>>> assigned major/minor devices.  The rest of userspace doesn't need to
>>> know about it; it can simply use the symlinks in /dev, but it is
>>> appropriate to let udev figure out the correct naming.
>> Can you point out an example of how this is done for Open Firmware
>> devices currently?
> Nope, because while it has been a theoretical concern, in practice the
> issue hasn't come up on any of the hardware I've worked on or I've
> seen patches for.
That is still this case here: it's a theoretical concern. Don't forget: 
we're talking about eight registers in the MPIC. There is no bus, no 
hotplug, nothing. Really, the only requirement is that somehow we can 
match the names used in the hardware documentation.
> Mostly this is because the device tree
> representations are internally self consistent;
> dependencies/connections are explicitly expressed with phandles or
> full paths which eliminates any need for enumeration in all the cases
> I've had to deal with.
The device tree on every platform contains devices which must be 
referenced by userspace. That is the problem we're trying to solve -- 
let's not get distracted by theoretical principles of enumeration.

The closest analogy might be serial devices, which unlike ethernet 
devices don't have other distinguishing information for udev to 
interpret. To my surprise, when I reverse the order of the serial nodes 
in the device tree, the ttyS0/S1 ordering reverses too. This is exactly 
the problem we were trying to avoid... but it seems nobody has solved it 
anywhere. :(

Hollis Blanchard
Mentor Graphics, Embedded Systems Division