Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis <hidden>
Date: 2011-01-07 20:30:52
Also in:
linuxppc-dev
On 01/07/2011 08:44 AM, Grant Likely wrote:
On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis [off-list ref] wrote:quoted
On 01/07/2011 07:48 AM, Grant Likely wrote:quoted
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