Re: Device tree node names

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

Grant, Rob, Segher, Arnd, Olof,

Can you please state if you agree with Mitch's opinion below? Thanks.

On 08/16/2012 03:36 PM, Mitch Bradley wrote:
> On 8/16/2012 9:34 AM, Stephen Warren wrote:
>> As I understand it, there is a rule when writing device tree files (and
>> bindings) that nodes should be named after the type of object they
>> represent, and not the particular instance of the object. Related, node
>> names should not be interpreted as data.
>>
>> This rules makes perfect sense when talking about nodes on a bus that
>> represent devices; something like:
>>
>>     i2c@7000c000 {
>>         compatible = "nvidia,tegra20-i2c";
>>         reg = <0x7000c000 0x100>;
>>         ...
>>     };
>>
>>     i2c@7000c400 {
>>         compatible = "nvidia,tegra20-i2c";
>>         reg = <0x7000c400 0x100>;
>>         ...
>>     };
>>
>> However, when nodes are being used to represent configuration
>> information inside a device node, or even when representing
>> pseudo-devices that don't directly exist on a specific bus, this rules
>> becomes quite annoying.
>>
>> As an example, consider a device that contains 10 voltage regulators
>> (named "ldon" in the chip documentation), and each needs some
>> configuration provided through DT. A simple binding might result in:
>>
>>     i2c@7000c000 {
>>         ldo0 {
>>             ... (configuration data here)
>>         };
>>         ldo1 {
>>             ...
>>         };
>>         ...
>>     };
>>
>> Where regulator "name"'s configuration is encoded into node "name".
>>
>> Instead, if we follow this rule precisely, we end up with something more
>> like:
>>
>>     i2c@7000c000 {
>>         #address-cells = <1>;
>>         #size-cells = <0>;
>>
>>         ldo@0 {
>>             reg = <0>;
>>             regulator-id = "ldo0";
>>             ...
>>         };
>>         ldo@1 {
>>             reg = <1>;
>>             regulator-id = "ldo1";
>>             ...
>>         };
>>         ...
>>     };
>>
>> This is a fair bit more wordy, and the only advantage appears to be that
>> it correctly conforms to some apparently arbitrary rule for node naming.
>>
>> Similar situations exist when describing the set of power sequences
>> needed to enable/disable a device [1] or pinctrl configurations (see
>> Linux kernel file arch/arm/boot/dts/tegra20-harmony.dts, node
>> /pinmux/pinmux where I haven't actually followed this rule correctly) etc.
>>
>> So, my question is: Can/should we relax this rule? Can we allow drivers
>> (bindings) to require specific node names for things, lookup up specific
>> configuration data by node name and/or enumerate all nodes, and parse
>> data out of the node names (e.g. the value n for nodes named LDOn in the
>> above example)?
> 
> As far as I'm concerned, within the privacy of your own node, you can do
> whatever you want.  Perhaps others will disagree...

If everyone agrees with this, it'll certainly give a lot more
flexibility for individual bindings to come up with simple
representations for configuration data within their own node.

Nodes that represent addressable buses would of course continue to use
standardized conventions in my opinion.

> The main "rule" for node names is that a user browsing the device tree
> can easily determine what something is.  Thus "ethernet" instead of
> "DEC,21140".
> 
> As an historical note, in early Open Boot, it was just the other way
> around.  I originally thought that node names should be precise - and
> the ill-considered "device_type" property gave the "generic"
> identification.   But it soon became clear that "precise" names were
> neither human-understandable nor actually precise. Pathnames looked like
> gobbledygook with strings of part numbers that only an expert could
> remember, and the evolution of part numbers, coupled with companies
> going out of business and other companies making compatible parts, made
> "precise" names change semi-randomly.  Thus was born the "generic names"
> rethink, in which the name became human-meaningful (but generally
> meaningless to software in any precise sense), device_type was
> deprecated, and compatible appeared, as a list.
> 
>>
>> [1]
>> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018433.html