On Wed, 28 Feb 2018, David Gibson wrote:
> On Mon, Feb 26, 2018 at 08:33:06AM +0100, Julia Lawall wrote:
> >
> >
> > On Sun, 25 Feb 2018, frowand.list@xxxxxxxxx wrote:
> >
> > > From: Frank Rowand <frowand.list@xxxxxxxxx>
> > >
> > > Hi All,
> > >
> > > I am once again out of my depth with bison and flex.
> > >
> > > 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]
> > > }
> > >
> > > 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.
> > >
> > > After applying patch 1/2, I get a syntax error when I try to
> > > compile a devicetree source with a label on the root node:
> > >
> > > $ dtc -O dts junk_lab.dts >junk
> > > Error: junk_lab.dts:3.9-10 syntax error
> > > FATAL ERROR: Unable to parse input tree
> > >
> > > Here are the first few lines of the source file:
> > >
> > > $ nl -ba junk_lab.dts | head
> > > 1 /dts-v1/;
> > > 2
> > > 3 myroot: / {
> > > 4 #address-cells = <0x1>;
> > > 5 #size-cells = <0x1>;
> > > 6 compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> > > 7 interrupt-parent = <0x1>;
> > > 8 model = "Qualcomm APQ8074 Dragonboard";
> > > 9
> > > 10 adsp-pil {
> > >
> > > I did my best to debug the cause of the symptom, and at one point
> > > tried removing the parse code that allows /memreserve/ to have
> > > a label, which is patch 2/2. This was just trying to better
> > > understand what was going on, not actually with the intent of
> > > submitting patch 2/2 for real. However, I can successfully
> > > compile a devicetree with a label on the root node when I
> > > have both patch 1/2 and patch 2/2 applied.
> > >
> > > Am I missing something that will let me add labels to the root
> > > node _without_ having to remove the capability of having
> > > labels on /memreserve/?
> >
> > OK, I read the mails out of order, so I see that you found the memreserve
> > problem. Is there a way that you expect the grammar to know whether the
> > label is part of the memreserve declaration or the devicetree declaration?
> > It needs to know immediately so it can choose between the rules
> > (memreserves and devicetree).
> >
> > Is it intentional that memreserve is recursive? Ie that lots of labels
> > should be allowed before a given DT_MEMRESERVE? If it were not recursive,
> > it might be smart enough to realize that the two kinds of DT_LABEL are
> > followed by different things.
>
> Yes, that's intentional. In general if something allows one label it
> should allow an arbitrary number.
OK, so then maybe the grammar can be refactored to match lots of labels
and then some rule that will contain some explicit tokens to help it
figure out when to figure out to switch from the memreserve state to the
device tree state.
julia
>
> --
> 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
>
--
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
