On 02/27/18 07:54, Rob Herring wrote: > On Sun, Feb 25, 2018 at 9:22 PM, <frowand.list@xxxxxxxxx> wrote: >> From: Frank Rowand <frowand.list@xxxxxxxxx> >> >> Hi All, >> >> I am once again out of my depth with bison and flex. > > Can't help on that one... > >> The Devicetree Specification and ePAPR both tell me that I can >> put a label on a node, as in: >> >> [label:] node-name[@unit-address] { >> [properties definitions] >> [child nodes] >> } > > Applying this to the root node would also imply that a unit-address is > also allowed which it is not. I'd contend that the root is special. Good point. Looks like I may have some additions to propose for the spec to clarify things. Also not mentioned in the spec: - "[label:]" should be something like "[label:} ..." (not sure of the syntax we use in the spec for multiples> - that labels can be put on /memreserve/ >> and do not make any mention of the root node as being different >> that any other node in this respect. >> >> However, the dtc implementation does not allow a label on the >> root node. I tried modifying the dtc parser to allow a label >> on the root node. The result is patch 1/2 in this series. > > Why would you want a label there? Because using "/" is too short or > the syntax for phandles using the path is too hard to remember (I > never can)? I'm not sure I _really_ want to, but I want to at least see if I can implement it. My quest started when I was trying to convert Laurent's R-Car overlays to sugar format. The first obstacle was that the target of most of the overlays is the root node. One way to do that is to put a label on the root node. Another approach would be for Linux to automagically add a phandle to the root node and create a corresponding symbol that the target could use for a phandle reference. Name of this magic symbol is an exercise left to the reader or bikeshedding. I'm exploring alternatives. Any other thoughts would be appreciated. Geert started another thread based on the rcar-du patch, where he says that not being able to have a label on the root node is one of two issues that is causing him issues with converting to sugar syntax. He says this "is the real blocker for me". So there is some indication that this may be a widespread issue. I have a long standing concern about arbitrary overlays being applied at arbitrary locations. Being able to target an overlay to the root of the tree can only make this issue worse. :-) So there may also be a need to create an administrative mechanism to provide some control. I don't really want to start on that yet, but it may be a gating factor before allowing an overlay loader in the Linux tree. -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html