Node names and properties names collision

Node names and properties names collision

[Neil Armstrong]

Hi,

I'm working on a full python device tree library to load blobs and manipulate the tree in-memory as an object tree (http://github.com/superna9999/pyfdt).
My testsuite strategy was to run the DTC testsuite and load every DTC generated dtbs, re-generate a DTS and compare the DTC dtb-to-dts output.

But I have a strange case using the Amlogic out-of-tree BSP dts where they use the same name for a sub-node and a property :

	efusekey:efusekey{
		keynum = <4>;
		key0 = <&key0>;
		key1 = <&key1>;
		key2 = <&key2>;
		key3 = <&key3>;
		key0:key0{
			keyname = "mac";
			offset = <0>;
			size = <6>;
		};
		key1:key1{
			keyname = "mac_bt";
			offset = <6>;
			size = <6>;
		};
		key2:key2{
			keyname = "mac_wifi";
			offset = <12>;
			size = <6>;
		};
		key3:key3{
			keyname = "usid";
			offset = <18>;
			size = <16>;
		};
	};

While reading the original ePAPR and the new linaro specifications, I was not able to find an answer....

Is it authorized ? Could this be clarified in the new specifications ?

Neil

RE: Node names and properties names collision

[Stuart Yoder]

> -----Original Message-----
> From: devicetree-spec-owner@vger.kernel.org [mailto:devicetree-spec-owner@vger.kernel.org] On Behalf Of
> Neil Armstrong
> Sent: Thursday, May 12, 2016 2:40 AM
> To: devicetree-spec@vger.kernel.org
> Subject: Node names and properties names collision
> 
> Hi,
> 
> I'm working on a full python device tree library to load blobs and manipulate the tree in-memory as an
> object tree (http://github.com/superna9999/pyfdt).
> My testsuite strategy was to run the DTC testsuite and load every DTC generated dtbs, re-generate a DTS
> and compare the DTC dtb-to-dts output.
> 
> But I have a strange case using the Amlogic out-of-tree BSP dts where they use the same name for a sub-
> node and a property :
> 
> 	efusekey:efusekey{
> 		keynum = <4>;
> 		key0 = <&key0>;
> 		key1 = <&key1>;
> 		key2 = <&key2>;
> 		key3 = <&key3>;
> 		key0:key0{
> 			keyname = "mac";
> 			offset = <0>;
> 			size = <6>;
> 		};
> 		key1:key1{
> 			keyname = "mac_bt";
> 			offset = <6>;
> 			size = <6>;
> 		};
> 		key2:key2{
> 			keyname = "mac_wifi";
> 			offset = <12>;
> 			size = <6>;
> 		};
> 		key3:key3{
> 			keyname = "usid";
> 			offset = <18>;
> 			size = <16>;
> 		};
> 	};
> 
> While reading the original ePAPR and the new linaro specifications, I was not able to find an answer....
> 
> Is it authorized ? Could this be clarified in the new specifications ?

Nodes and properties can inherently be differentiated, so there should be
no ambiguity if they happen to have the same name.  That being said, in practice
I don't think this situation happens.  A device tree describes hardware.  A node
name "should describe the general class of the device".  Property names
should be meaninful and if they are non-standard should have a organization
specific prefix.

The DTS example above seems to be a horrible example and follows none of those conventions.
There are no compatible strings, the node names don't seem to be describing
hardware.  And not sure why you would need properties pointing to subnodes.  So,
the syntax/semantics of device tree allows it, but nothing like that example would
ever pass a public review.

Thanks,
Stuart

Re: Node names and properties names collision

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 3006 bytes --]

On Thu, May 12, 2016 at 04:22:39PM +0000, Stuart Yoder wrote:
> 
> 
> > -----Original Message-----
> > From: devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of
> > Neil Armstrong
> > Sent: Thursday, May 12, 2016 2:40 AM
> > To: devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Node names and properties names collision
> > 
> > Hi,
> > 
> > I'm working on a full python device tree library to load blobs and manipulate the tree in-memory as an
> > object tree (http://github.com/superna9999/pyfdt).
> > My testsuite strategy was to run the DTC testsuite and load every DTC generated dtbs, re-generate a DTS
> > and compare the DTC dtb-to-dts output.
> > 
> > But I have a strange case using the Amlogic out-of-tree BSP dts where they use the same name for a sub-
> > node and a property :
> > 
> > 	efusekey:efusekey{
> > 		keynum = <4>;
> > 		key0 = <&key0>;
> > 		key1 = <&key1>;
> > 		key2 = <&key2>;
> > 		key3 = <&key3>;
> > 		key0:key0{
> > 			keyname = "mac";
> > 			offset = <0>;
> > 			size = <6>;
> > 		};
> > 		key1:key1{
> > 			keyname = "mac_bt";
> > 			offset = <6>;
> > 			size = <6>;
> > 		};
> > 		key2:key2{
> > 			keyname = "mac_wifi";
> > 			offset = <12>;
> > 			size = <6>;
> > 		};
> > 		key3:key3{
> > 			keyname = "usid";
> > 			offset = <18>;
> > 			size = <16>;
> > 		};
> > 	};
> > 
> > While reading the original ePAPR and the new linaro specifications, I was not able to find an answer....
> > 
> > Is it authorized ? Could this be clarified in the new specifications ?
> 
> Nodes and properties can inherently be differentiated, so there should be
> no ambiguity if they happen to have the same name.

Yes, it's permitted.  Properties and subnodes of a node live in
different logical namespaces.

> That being said, in practice
> I don't think this situation happens.

It's rare, but it has occurred in practice.  A number of old PowerMac
machines had DTs with (IIRC it was both an "l2-cache" property and
"l2-cache" subnode under the cpu nodes).

> A device tree describes hardware.  A node
> name "should describe the general class of the device".  Property names
> should be meaninful and if they are non-standard should have a organization
> specific prefix.
> 
> The DTS example above seems to be a horrible example and follows none of those conventions.
> There are no compatible strings, the node names don't seem to be describing
> hardware.  And not sure why you would need properties pointing to subnodes.  So,
> the syntax/semantics of device tree allows it, but nothing like that example would
> ever pass a public review.

That particular example does indeed look horrible.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]