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

[Herve Codina <herve.codina@bootlin.com>]

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é