Re: [RFC PATCH 14/15] libfdt: Handle unknown tags on dtb modifications

Herve Codina
2026-04-07T15:41:23Z

Hi Luca,

On Wed, 01 Apr 2026 17:18:54 +0200
"Luca Ceresoli" <luca.ceresoli@bootlin.com> wrote:

...
> > - An unknown tag out of any node (i.e located before the first
> > FDT_BEGIN_NODE or after the last FDT_END_NODE is a global tag
> ^
> missing ')'
> > related to the dtb itself.
>
> Out of curiosity, is there a real use case for global tags after
> FDT_END_NODE?

Well what could be use cases in the future?

We talk about unknown tag and nothing prevent an unknown tag to be after
the last FDT_END_NODE tag in the future.

In my RFC series adding support for addons, I added FDT_IMPORT_SYM tags at
the end of the addon dtb and so a global tags were available after a
FDT_END_NODE tag.

In the end of the commit log introducing FDT_IMPORT_SYM tags [0], the
location of those tags is mentioned:
--- 8< ---
If FDT_IMPORT_SYM tags are present in the dtb, they are present after
the root node definition (i.e. after the FDT_END_NODE related to the
first FDT_BEGIN_NODE).
--- 8< ---

Also in tests related to import symbols [0], you can have a look look at
the tests/metadata_importsyms.dtb.expect file and you will find:
--- 8< ---
--- /dev/null
+++ b/tests/metadata_importsyms.dtb.expect
@@ -0,0 +1,8 @@
+/dts-v1/;
+/addon/;
+
+/ {
+ prop = <0x00000001>;
+};
+// [FDT_IMPORT_SYM] 'base_a' (foo,bar)
+// [FDT_IMPORT_SYM] 'base_b' (foo,baz)
--- 8< ---

This is the expected result when the metadata_importsyms.dtb is dumped using
fdtdump.

fdtdump dumps a dtb in a linear way starting from the beginning to the end
of file.

The FDT_END_NODE tag is represented by the '};' sequence (end of node).
FDT_IMPORT_SYM tags are present after the end of node and so between the
FDT_END_NODE tag and the FDT_END tag.

Not sure I will keep those tags at the end of dtb when I rework the series
on top of "structured tags" but well, this was a real use case.

[0] https://lore.kernel.org/devicetree-compiler/20260112142009.1006236-36-herve.codina@bootlin.com/
[1] https://lore.kernel.org/devicetree-compiler/20260112142009.1006236-37-herve.codina@bootlin.com/

Best regards,
Hervé