On Tue, May 20, 2014 at 1:50 AM, Grant Likely <[email protected]> wrote: > On Sun, 18 May 2014 18:11:07 -0500, Rob Herring <[email protected]> wrote: >> On Sun, May 18, 2014 at 12:01 PM, Ezequiel Garcia >> <[email protected]> wrote: >> > When creating a device object for a devicetree node, the device name >> > is created by using the node name and the 'reg' property, to make a name >> > such as "a000.foo_device". >> > >> > For certain devices without an associated address, and hence no 'reg' >> > property, >> > the current code attempts to make a unique name, by using a global integer. >> > Names look like "foo_device.1", "bar_device.2", and so on. >> > Examples of such devices are: gpio-keys', backlights and rotary-encoders. >> > >> > The system cannot know such devices name before hand, given they are >> > determined >> > by the kernel probe order and by the nodes present in the devicetree. This >> > can >> > be problematic, on systems that are tied to the device's name, e.g. when >> > catching hotplug events. > > The device's uevent file in sysfs contains both the ->name and > ->full_name values for a node. Does that help you? > > The big problem is not the structure under /sys/devices, but rather the > symlinks to devices that appear under /sys/bus/*/devices. If two leaf > nodes have the same name, then they will conflict when they get added to > a bus_type's array of devices. > > Another way to handle it is to only add the suffix when a conflict > actually occurs. That requires checking first whether or not a name will > conflict and ammending it only when that happens. I don't know if that > can be done nicely. I'll take a look.
That was my idea as well and to move to a local number so you have something like deviceA, deviceA.1, deviceB, deviceB.1 (maybe the number is always appended). Perhaps a random number instead so no one expects the names to be an ABI. ;) I think it should be doable. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
