[RFC] MPIC Bindings and Bindings for AMP Systems
Blanchard, Hollis
Hollis_Blanchard at mentor.com
Sat Jan 8 07:30:52 EST 2011
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
More information about the devicetree-discuss
mailing list