> -----Original Message----- > From: devicetree-spec-owner@xxxxxxxxxxxxxxx [mailto:devicetree-spec-owner@xxxxxxxxxxxxxxx] On Behalf Of > Neil Armstrong > Sent: Thursday, May 12, 2016 2:40 AM > To: devicetree-spec@xxxxxxxxxxxxxxx > 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 ��.n��������+%������w��{.n����z�{���n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
