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/?
Thanks for any suggestions or directions to pursue debugging.
-Frank
Frank Rowand (2):
dtc: allow label on root node of devicetree
dtc: disallow label on /memreserve/
dtc-parser.y | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
Frank Rowand <frank.rowand@xxxxxxxx>
--
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
