On Tue, Feb 27, 2018 at 09:58:00AM -0800, Frank Rowand wrote:
> 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>
Right. In general you can have multiple labels on anything.
> - that labels can be put on /memreserve/
So, like labels within property values, labels on memreserve will only
do something measurable with -Oasm output, and isn't really useful
with modern device tree workflows.
> >> 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.
You should also be able to use &{/} to reference the root node with
sugar syntax. I believe that should generate a target-path format
fragment. And if it doesn't, we should fix that.
> 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 really dislike that option since it adds more complexity that any
overlay applied would need to know.
> 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
--
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:
signature.asc
Description: PGP signature
