* [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value
2026-01-12 14:18 [RFC PATCH 00/77] Add support for dtb metadata and addon device-trees Herve Codina
@ 2026-01-12 14:18 ` Herve Codina
2026-01-12 14:55 ` Ayush Singh
2026-01-13 3:08 ` David Gibson
2026-01-12 14:18 ` [RFC PATCH 02/77] Introduce v18 dtb version Herve Codina
` (78 subsequent siblings)
79 siblings, 2 replies; 160+ messages in thread
From: Herve Codina @ 2026-01-12 14:18 UTC (permalink / raw)
To: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli,
Thomas Petazzoni, Herve Codina
strspn() returns a size_t value.
The function is called in several places and in all places this value is
stored in a size_t variable except in check_node_name_chars_strict().
Fix the variable type used in check_node_name_chars_strict().
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
checks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/checks.c b/checks.c
index 5d09216..041e565 100644
--- a/checks.c
+++ b/checks.c
@@ -324,7 +324,7 @@ ERROR(node_name_chars, check_node_name_chars, NODECHARS);
static void check_node_name_chars_strict(struct check *c, struct dt_info *dti,
struct node *node)
{
- int n = strspn(node->name, c->data);
+ size_t n = strspn(node->name, c->data);
if (n < node->basenamelen)
FAIL(c, dti, node, "Character '%c' not recommended in node name",
--
2.52.0
^ permalink raw reply related [flat|nested] 160+ messages in thread* Re: [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value
2026-01-12 14:18 ` [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value Herve Codina
@ 2026-01-12 14:55 ` Ayush Singh
2026-01-13 3:08 ` David Gibson
1 sibling, 0 replies; 160+ messages in thread
From: Ayush Singh @ 2026-01-12 14:55 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
On 1/12/26 7:48 PM, Herve Codina wrote:
> strspn() returns a size_t value.
>
> The function is called in several places and in all places this value is
> stored in a size_t variable except in check_node_name_chars_strict().
>
> Fix the variable type used in check_node_name_chars_strict().
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> checks.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/checks.c b/checks.c
> index 5d09216..041e565 100644
> --- a/checks.c
> +++ b/checks.c
> @@ -324,7 +324,7 @@ ERROR(node_name_chars, check_node_name_chars, NODECHARS);
> static void check_node_name_chars_strict(struct check *c, struct dt_info *dti,
> struct node *node)
> {
> - int n = strspn(node->name, c->data);
> + size_t n = strspn(node->name, c->data);
>
> if (n < node->basenamelen)
> FAIL(c, dti, node, "Character '%c' not recommended in node name",
Reviewed-by: Ayush Singh <ayush@beagleboard.org>
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value
2026-01-12 14:18 ` [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value Herve Codina
2026-01-12 14:55 ` Ayush Singh
@ 2026-01-13 3:08 ` David Gibson
2026-01-13 4:42 ` David Gibson
1 sibling, 1 reply; 160+ messages in thread
From: David Gibson @ 2026-01-13 3:08 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
On Mon, Jan 12, 2026 at 03:18:51PM +0100, Herve Codina wrote:
> strspn() returns a size_t value.
>
> The function is called in several places and in all places this value is
> stored in a size_t variable except in check_node_name_chars_strict().
>
> Fix the variable type used in check_node_name_chars_strict().
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
This one makes sense regardless of the rest, so, merged.
> ---
> checks.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/checks.c b/checks.c
> index 5d09216..041e565 100644
> --- a/checks.c
> +++ b/checks.c
> @@ -324,7 +324,7 @@ ERROR(node_name_chars, check_node_name_chars, NODECHARS);
> static void check_node_name_chars_strict(struct check *c, struct dt_info *dti,
> struct node *node)
> {
> - int n = strspn(node->name, c->data);
> + size_t n = strspn(node->name, c->data);
>
> if (n < node->basenamelen)
> FAIL(c, dti, node, "Character '%c' not recommended in node name",
> --
> 2.52.0
>
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value
2026-01-13 3:08 ` David Gibson
@ 2026-01-13 4:42 ` David Gibson
2026-01-13 8:02 ` Herve Codina
0 siblings, 1 reply; 160+ messages in thread
From: David Gibson @ 2026-01-13 4:42 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]
On Tue, Jan 13, 2026 at 02:08:54PM +1100, David Gibson wrote:
> On Mon, Jan 12, 2026 at 03:18:51PM +0100, Herve Codina wrote:
> > strspn() returns a size_t value.
> >
> > The function is called in several places and in all places this value is
> > stored in a size_t variable except in check_node_name_chars_strict().
> >
> > Fix the variable type used in check_node_name_chars_strict().
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
>
> This one makes sense regardless of the rest, so, merged.
I spoke too soon. This causes a compile error:
https://github.com/dgibson/dtc/actions/runs/20944813954/job/60185662154#step:5:130
For some reason it's only showing on the make build, not meson. I
guess there must be a mismatch in which warnings are enabled.
>
> > ---
> > checks.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/checks.c b/checks.c
> > index 5d09216..041e565 100644
> > --- a/checks.c
> > +++ b/checks.c
> > @@ -324,7 +324,7 @@ ERROR(node_name_chars, check_node_name_chars, NODECHARS);
> > static void check_node_name_chars_strict(struct check *c, struct dt_info *dti,
> > struct node *node)
> > {
> > - int n = strspn(node->name, c->data);
> > + size_t n = strspn(node->name, c->data);
> >
> > if (n < node->basenamelen)
> > FAIL(c, dti, node, "Character '%c' not recommended in node name",
> > --
> > 2.52.0
> >
> >
>
> --
> David Gibson (he or they) | 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
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value
2026-01-13 4:42 ` David Gibson
@ 2026-01-13 8:02 ` Herve Codina
0 siblings, 0 replies; 160+ messages in thread
From: Herve Codina @ 2026-01-13 8:02 UTC (permalink / raw)
To: David Gibson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
Hi David,
On Tue, 13 Jan 2026 15:42:31 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Tue, Jan 13, 2026 at 02:08:54PM +1100, David Gibson wrote:
> > On Mon, Jan 12, 2026 at 03:18:51PM +0100, Herve Codina wrote:
> > > strspn() returns a size_t value.
> > >
> > > The function is called in several places and in all places this value is
> > > stored in a size_t variable except in check_node_name_chars_strict().
> > >
> > > Fix the variable type used in check_node_name_chars_strict().
> > >
> > > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> >
> > This one makes sense regardless of the rest, so, merged.
>
> I spoke too soon. This causes a compile error:
>
> https://github.com/dgibson/dtc/actions/runs/20944813954/job/60185662154#step:5:130
>
> For some reason it's only showing on the make build, not meson. I
> guess there must be a mismatch in which warnings are enabled.
I used only meson and so I missed the signed/unsigned comparison warning.
I will remove this signed/unsigned warning in the next iteration.
Best regards,
Hervé
^ permalink raw reply [flat|nested] 160+ messages in thread
* [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-12 14:18 [RFC PATCH 00/77] Add support for dtb metadata and addon device-trees Herve Codina
2026-01-12 14:18 ` [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value Herve Codina
@ 2026-01-12 14:18 ` Herve Codina
2026-01-15 0:12 ` David Gibson
2026-01-12 14:18 ` [RFC PATCH 03/77] libfdt: Introduce fdt_next_tag_full() and use it in fdt_next_tag() Herve Codina
` (77 subsequent siblings)
79 siblings, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-12 14:18 UTC (permalink / raw)
To: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli,
Thomas Petazzoni, Herve Codina
This v18 version will add support for
- metadata in device-tree blobs in order to have a better handling of
phandles and unresolved references.
- Addon device-tree blob (successor of device-tree overlay)
- Import and export symbols feature
- multiple trees in a addon device-tree blob (i.e. root device tree and
orphan node tree)
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
dtc.h | 2 +-
fdtdump.c | 2 +-
flattree.c | 2 ++
libfdt/fdt.h | 1 +
libfdt/fdt_rw.c | 13 +++++++------
libfdt/libfdt.h | 2 +-
tests/pylibfdt_tests.py | 2 +-
tests/trees.S | 2 +-
8 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/dtc.h b/dtc.h
index 3a220b9..186caad 100644
--- a/dtc.h
+++ b/dtc.h
@@ -29,7 +29,7 @@
#define debug(...)
#endif
-#define DEFAULT_FDT_VERSION 17
+#define DEFAULT_FDT_VERSION 18
/*
* Command line options
diff --git a/fdtdump.c b/fdtdump.c
index d424869..ec25edf 100644
--- a/fdtdump.c
+++ b/fdtdump.c
@@ -18,7 +18,7 @@
#include "util.h"
#define FDT_MAGIC_SIZE 4
-#define MAX_VERSION 17U
+#define MAX_VERSION 18U
#define ALIGN(x, a) (((x) + ((a) - 1)) & ~((a) - 1))
#define PALIGN(p, a) ((void *)(ALIGN((uintptr_t)(p), (a))))
diff --git a/flattree.c b/flattree.c
index 30e6de2..c3887da 100644
--- a/flattree.c
+++ b/flattree.c
@@ -30,6 +30,8 @@ static struct version_info {
FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_NOPS},
{17, 16, FDT_V17_SIZE,
FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_STRUCTSIZE|FTF_NOPS},
+ {18, 18, FDT_V18_SIZE,
+ FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_STRUCTSIZE|FTF_NOPS},
};
struct emitter {
diff --git a/libfdt/fdt.h b/libfdt/fdt.h
index a07abfc..9372353 100644
--- a/libfdt/fdt.h
+++ b/libfdt/fdt.h
@@ -62,5 +62,6 @@ struct fdt_property {
#define FDT_V3_SIZE (FDT_V2_SIZE + sizeof(fdt32_t))
#define FDT_V16_SIZE FDT_V3_SIZE
#define FDT_V17_SIZE (FDT_V16_SIZE + sizeof(fdt32_t))
+#define FDT_V18_SIZE FDT_V17_SIZE
#endif /* FDT_H */
diff --git a/libfdt/fdt_rw.c b/libfdt/fdt_rw.c
index 7475caf..00e32bb 100644
--- a/libfdt/fdt_rw.c
+++ b/libfdt/fdt_rw.c
@@ -28,13 +28,13 @@ static int fdt_rw_probe_(void *fdt)
return 0;
FDT_RO_PROBE(fdt);
- if (!can_assume(LATEST) && fdt_version(fdt) < 17)
+ if (!can_assume(LATEST) && fdt_version(fdt) < 18)
return -FDT_ERR_BADVERSION;
if (fdt_blocks_misordered_(fdt, sizeof(struct fdt_reserve_entry),
fdt_size_dt_struct(fdt)))
return -FDT_ERR_BADLAYOUT;
- if (!can_assume(LATEST) && fdt_version(fdt) > 17)
- fdt_set_version(fdt, 17);
+ if (!can_assume(LATEST) && fdt_version(fdt) > 18)
+ fdt_set_version(fdt, 18);
return 0;
}
@@ -455,7 +455,8 @@ int fdt_open_into(const void *fdt, void *buf, int bufsize)
err = fdt_move(fdt, buf, bufsize);
if (err)
return err;
- fdt_set_version(buf, 17);
+ fdt_set_version(buf, 18);
+ fdt_set_last_comp_version(buf, 18);
fdt_set_size_dt_struct(buf, struct_size);
fdt_set_totalsize(buf, bufsize);
return 0;
@@ -484,8 +485,8 @@ int fdt_open_into(const void *fdt, void *buf, int bufsize)
fdt_set_magic(buf, FDT_MAGIC);
fdt_set_totalsize(buf, bufsize);
- fdt_set_version(buf, 17);
- fdt_set_last_comp_version(buf, 16);
+ fdt_set_version(buf, 18);
+ fdt_set_last_comp_version(buf, 18);
fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
return 0;
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index 7a10f66..c5cd35d 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -15,7 +15,7 @@ extern "C" {
#define FDT_FIRST_SUPPORTED_VERSION 0x02
#define FDT_LAST_COMPATIBLE_VERSION 0x10
-#define FDT_LAST_SUPPORTED_VERSION 0x11
+#define FDT_LAST_SUPPORTED_VERSION 0x12
/* Error codes: informative error codes */
#define FDT_ERR_NOTFOUND 1
diff --git a/tests/pylibfdt_tests.py b/tests/pylibfdt_tests.py
index a4f73ed..373e11a 100644
--- a/tests/pylibfdt_tests.py
+++ b/tests/pylibfdt_tests.py
@@ -288,7 +288,7 @@ class PyLibfdtBasicTests(unittest.TestCase):
self.assertEqual(self.fdt.off_dt_struct(), 88)
self.assertEqual(self.fdt.off_dt_strings(), 652)
self.assertEqual(self.fdt.off_mem_rsvmap(), 40)
- self.assertEqual(self.fdt.version(), 17)
+ self.assertEqual(self.fdt.version(), 18)
self.assertEqual(self.fdt.last_comp_version(), 16)
self.assertEqual(self.fdt.boot_cpuid_phys(), 0)
self.assertEqual(self.fdt.size_dt_strings(), 105)
diff --git a/tests/trees.S b/tests/trees.S
index d69f7f1..ecd43bc 100644
--- a/tests/trees.S
+++ b/tests/trees.S
@@ -17,7 +17,7 @@
fdtlong (\tree\()_struct - \tree)
fdtlong (\tree\()_strings - \tree)
fdtlong (\tree\()_rsvmap - \tree)
- fdtlong 0x11
+ fdtlong 0x12
fdtlong 0x10
fdtlong 0
fdtlong (\tree\()_strings_end - \tree\()_strings)
--
2.52.0
^ permalink raw reply related [flat|nested] 160+ messages in thread* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-12 14:18 ` [RFC PATCH 02/77] Introduce v18 dtb version Herve Codina
@ 2026-01-15 0:12 ` David Gibson
2026-01-16 9:09 ` Herve Codina
0 siblings, 1 reply; 160+ messages in thread
From: David Gibson @ 2026-01-15 0:12 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 6238 bytes --]
On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> This v18 version will add support for
> - metadata in device-tree blobs in order to have a better handling of
> phandles and unresolved references.
> - Addon device-tree blob (successor of device-tree overlay)
> - Import and export symbols feature
> - multiple trees in a addon device-tree blob (i.e. root device tree and
> orphan node tree)
So, once this patch is applied, the rest of the series pretty much has
to be applied "atomically" - otherwise a version built in the interim
will be lying in saying that it supports v18.
I therefore suggest moving any changes that *can* be moved before this
patch, should be moved before this patch. That will assist in
reviewing and merging the series piecemeal, rather than as a single
giant blob.
Regarding the content itself. It seems like this is a pretty major
change to the dtb format - maybe that would suggest bumping the
version by more than one (e.g. like we went from v3 to v16 in the
past).
It would also be nice to have some docs for the new dtb extensions
before or at the same time as this.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> dtc.h | 2 +-
> fdtdump.c | 2 +-
> flattree.c | 2 ++
> libfdt/fdt.h | 1 +
> libfdt/fdt_rw.c | 13 +++++++------
> libfdt/libfdt.h | 2 +-
> tests/pylibfdt_tests.py | 2 +-
> tests/trees.S | 2 +-
> 8 files changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/dtc.h b/dtc.h
> index 3a220b9..186caad 100644
> --- a/dtc.h
> +++ b/dtc.h
> @@ -29,7 +29,7 @@
> #define debug(...)
> #endif
>
> -#define DEFAULT_FDT_VERSION 17
> +#define DEFAULT_FDT_VERSION 18
>
> /*
> * Command line options
> diff --git a/fdtdump.c b/fdtdump.c
> index d424869..ec25edf 100644
> --- a/fdtdump.c
> +++ b/fdtdump.c
> @@ -18,7 +18,7 @@
> #include "util.h"
>
> #define FDT_MAGIC_SIZE 4
> -#define MAX_VERSION 17U
> +#define MAX_VERSION 18U
>
> #define ALIGN(x, a) (((x) + ((a) - 1)) & ~((a) - 1))
> #define PALIGN(p, a) ((void *)(ALIGN((uintptr_t)(p), (a))))
> diff --git a/flattree.c b/flattree.c
> index 30e6de2..c3887da 100644
> --- a/flattree.c
> +++ b/flattree.c
> @@ -30,6 +30,8 @@ static struct version_info {
> FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_NOPS},
> {17, 16, FDT_V17_SIZE,
> FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_STRUCTSIZE|FTF_NOPS},
> + {18, 18, FDT_V18_SIZE,
> + FTF_BOOTCPUID|FTF_STRTABSIZE|FTF_STRUCTSIZE|FTF_NOPS},
> };
>
> struct emitter {
> diff --git a/libfdt/fdt.h b/libfdt/fdt.h
> index a07abfc..9372353 100644
> --- a/libfdt/fdt.h
> +++ b/libfdt/fdt.h
> @@ -62,5 +62,6 @@ struct fdt_property {
> #define FDT_V3_SIZE (FDT_V2_SIZE + sizeof(fdt32_t))
> #define FDT_V16_SIZE FDT_V3_SIZE
> #define FDT_V17_SIZE (FDT_V16_SIZE + sizeof(fdt32_t))
> +#define FDT_V18_SIZE FDT_V17_SIZE
>
> #endif /* FDT_H */
> diff --git a/libfdt/fdt_rw.c b/libfdt/fdt_rw.c
> index 7475caf..00e32bb 100644
> --- a/libfdt/fdt_rw.c
> +++ b/libfdt/fdt_rw.c
> @@ -28,13 +28,13 @@ static int fdt_rw_probe_(void *fdt)
> return 0;
> FDT_RO_PROBE(fdt);
>
> - if (!can_assume(LATEST) && fdt_version(fdt) < 17)
> + if (!can_assume(LATEST) && fdt_version(fdt) < 18)
> return -FDT_ERR_BADVERSION;
> if (fdt_blocks_misordered_(fdt, sizeof(struct fdt_reserve_entry),
> fdt_size_dt_struct(fdt)))
> return -FDT_ERR_BADLAYOUT;
> - if (!can_assume(LATEST) && fdt_version(fdt) > 17)
> - fdt_set_version(fdt, 17);
> + if (!can_assume(LATEST) && fdt_version(fdt) > 18)
> + fdt_set_version(fdt, 18);
>
> return 0;
> }
> @@ -455,7 +455,8 @@ int fdt_open_into(const void *fdt, void *buf, int bufsize)
> err = fdt_move(fdt, buf, bufsize);
> if (err)
> return err;
> - fdt_set_version(buf, 17);
> + fdt_set_version(buf, 18);
> + fdt_set_last_comp_version(buf, 18);
> fdt_set_size_dt_struct(buf, struct_size);
> fdt_set_totalsize(buf, bufsize);
> return 0;
> @@ -484,8 +485,8 @@ int fdt_open_into(const void *fdt, void *buf, int bufsize)
>
> fdt_set_magic(buf, FDT_MAGIC);
> fdt_set_totalsize(buf, bufsize);
> - fdt_set_version(buf, 17);
> - fdt_set_last_comp_version(buf, 16);
> + fdt_set_version(buf, 18);
> + fdt_set_last_comp_version(buf, 18);
> fdt_set_boot_cpuid_phys(buf, fdt_boot_cpuid_phys(fdt));
>
> return 0;
> diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
> index 7a10f66..c5cd35d 100644
> --- a/libfdt/libfdt.h
> +++ b/libfdt/libfdt.h
> @@ -15,7 +15,7 @@ extern "C" {
>
> #define FDT_FIRST_SUPPORTED_VERSION 0x02
> #define FDT_LAST_COMPATIBLE_VERSION 0x10
> -#define FDT_LAST_SUPPORTED_VERSION 0x11
> +#define FDT_LAST_SUPPORTED_VERSION 0x12
>
> /* Error codes: informative error codes */
> #define FDT_ERR_NOTFOUND 1
> diff --git a/tests/pylibfdt_tests.py b/tests/pylibfdt_tests.py
> index a4f73ed..373e11a 100644
> --- a/tests/pylibfdt_tests.py
> +++ b/tests/pylibfdt_tests.py
> @@ -288,7 +288,7 @@ class PyLibfdtBasicTests(unittest.TestCase):
> self.assertEqual(self.fdt.off_dt_struct(), 88)
> self.assertEqual(self.fdt.off_dt_strings(), 652)
> self.assertEqual(self.fdt.off_mem_rsvmap(), 40)
> - self.assertEqual(self.fdt.version(), 17)
> + self.assertEqual(self.fdt.version(), 18)
> self.assertEqual(self.fdt.last_comp_version(), 16)
> self.assertEqual(self.fdt.boot_cpuid_phys(), 0)
> self.assertEqual(self.fdt.size_dt_strings(), 105)
> diff --git a/tests/trees.S b/tests/trees.S
> index d69f7f1..ecd43bc 100644
> --- a/tests/trees.S
> +++ b/tests/trees.S
> @@ -17,7 +17,7 @@
> fdtlong (\tree\()_struct - \tree)
> fdtlong (\tree\()_strings - \tree)
> fdtlong (\tree\()_rsvmap - \tree)
> - fdtlong 0x11
> + fdtlong 0x12
> fdtlong 0x10
> fdtlong 0
> fdtlong (\tree\()_strings_end - \tree\()_strings)
> --
> 2.52.0
>
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-15 0:12 ` David Gibson
@ 2026-01-16 9:09 ` Herve Codina
2026-01-19 5:13 ` David Gibson
0 siblings, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-16 9:09 UTC (permalink / raw)
To: David Gibson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
Hi David,
On Thu, 15 Jan 2026 11:12:49 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > This v18 version will add support for
> > - metadata in device-tree blobs in order to have a better handling of
> > phandles and unresolved references.
> > - Addon device-tree blob (successor of device-tree overlay)
> > - Import and export symbols feature
> > - multiple trees in a addon device-tree blob (i.e. root device tree and
> > orphan node tree)
>
> So, once this patch is applied, the rest of the series pretty much has
> to be applied "atomically" - otherwise a version built in the interim
> will be lying in saying that it supports v18.
>
> I therefore suggest moving any changes that *can* be moved before this
> patch, should be moved before this patch. That will assist in
> reviewing and merging the series piecemeal, rather than as a single
> giant blob.
>
>
> Regarding the content itself. It seems like this is a pretty major
> change to the dtb format - maybe that would suggest bumping the
> version by more than one (e.g. like we went from v3 to v16 in the
> past).
I see your point.
Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
related to the generic tag value definition to support those 'unknown tag'
could help here.
As a reminder here, this generic tag value definition consist in:
--- 8< ---
A tag value is on 32bits. We can define the structure of this value.
- bit 31 (msb):
- 0: This is not a new kind to tag and so it doesn't follow this definition.
All existing tags are in this category
- 1: New kind of tag adopting this definition
- bits 30..28:
tag data length encoding
0b000: No data related to the tag
0b001: 1 data cell (u32) directly follows the tag
0b010: 2 data cells (2 u32) directly follow the tag
...
0b110: 6 data cells (6 u32) directly follow the tag
0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
of data available just after this cell (including any padding
if needed).
Because this size include some possible padding, its value is a
multiple of 4 bytes.
The offset of the tag + 4 + size points to the next tag.
- bit 27..0
tag specific identifier
--- 8< ---
I mean dtb version v20 could be:
- New header size with dt_flags added in the header (if this new field is
kept).
- Support for the generic tag values and so the notion of 'unknown tag'
With that done, everything else added afterward will have no impact on the
dtb format itself.
Only libfdt and dtc will have versions defined at some point with support for
some new flags or new keyword.
What do you think about this v20 dtb version?
>
> It would also be nice to have some docs for the new dtb extensions
> before or at the same time as this.
Yes, the generic tag value definition.
[1] https://lore.kernel.org/all/20260114171822.2a44d2a5@bootlin.com/
Best regards
Hervé
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-16 9:09 ` Herve Codina
@ 2026-01-19 5:13 ` David Gibson
2026-01-19 9:48 ` Herve Codina
2026-01-20 20:38 ` Rob Herring
0 siblings, 2 replies; 160+ messages in thread
From: David Gibson @ 2026-01-19 5:13 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 4494 bytes --]
On Fri, Jan 16, 2026 at 10:09:34AM +0100, Herve Codina wrote:
> Hi David,
>
> On Thu, 15 Jan 2026 11:12:49 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > > This v18 version will add support for
> > > - metadata in device-tree blobs in order to have a better handling of
> > > phandles and unresolved references.
> > > - Addon device-tree blob (successor of device-tree overlay)
> > > - Import and export symbols feature
> > > - multiple trees in a addon device-tree blob (i.e. root device tree and
> > > orphan node tree)
> >
> > So, once this patch is applied, the rest of the series pretty much has
> > to be applied "atomically" - otherwise a version built in the interim
> > will be lying in saying that it supports v18.
> >
> > I therefore suggest moving any changes that *can* be moved before this
> > patch, should be moved before this patch. That will assist in
> > reviewing and merging the series piecemeal, rather than as a single
> > giant blob.
> >
> >
> > Regarding the content itself. It seems like this is a pretty major
> > change to the dtb format - maybe that would suggest bumping the
> > version by more than one (e.g. like we went from v3 to v16 in the
> > past).
>
> I see your point.
>
> Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
> related to the generic tag value definition to support those 'unknown tag'
> could help here.
Having a standard encoding of tag length so unknown tags can be
skipped is a reasonable idea. I think you do need provision to mark a
tag as "safe to ignore" or not - e.g. something like FDT_BEGIN_NODE
could never be safely ignored.
> As a reminder here, this generic tag value definition consist in:
> --- 8< ---
> A tag value is on 32bits. We can define the structure of this value.
> - bit 31 (msb):
> - 0: This is not a new kind to tag and so it doesn't follow this definition.
> All existing tags are in this category
> - 1: New kind of tag adopting this definition
>
> - bits 30..28:
> tag data length encoding
> 0b000: No data related to the tag
> 0b001: 1 data cell (u32) directly follows the tag
> 0b010: 2 data cells (2 u32) directly follow the tag
> ...
> 0b110: 6 data cells (6 u32) directly follow the tag
> 0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
> of data available just after this cell (including any padding
> if needed).
I'd suggesting giving a byte length not including alignment padding.
That way if you wanted to encode a bytestring in there, you wouldn't
need a way of encoding the unpadded length in adddition to the
standard way encoding the padded length.
> Because this size include some possible padding, its value is a
> multiple of 4 bytes.
> The offset of the tag + 4 + size points to the next tag.
>
>
> - bit 27..0
> tag specific identifier
> --- 8< ---
>
> I mean dtb version v20 could be:
>
> - New header size with dt_flags added in the header (if this new field is
> kept).
>
> - Support for the generic tag values and so the notion of 'unknown tag'
>
> With that done, everything else added afterward will have no impact on the
> dtb format itself.
Well... maybe. It's not entirely clear to me whether all the new tags
can be safely ignored by something that doesn't understand them.
e.g. a consumer can't safely ignore the tags which give unresolved
phandle references if it then expects the phandle values in the actual
property values to be correct.
>
> Only libfdt and dtc will have versions defined at some point with support for
> some new flags or new keyword.
>
> What do you think about this v20 dtb version?
>
> >
> > It would also be nice to have some docs for the new dtb extensions
> > before or at the same time as this.
>
> Yes, the generic tag value definition.
We'd want that, but it's not enough. The specific tag types should be
documented as well.
>
>
> [1] https://lore.kernel.org/all/20260114171822.2a44d2a5@bootlin.com/
>
> Best regards
> Hervé
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-19 5:13 ` David Gibson
@ 2026-01-19 9:48 ` Herve Codina
2026-01-28 1:49 ` David Gibson
2026-01-20 20:38 ` Rob Herring
1 sibling, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-19 9:48 UTC (permalink / raw)
To: David Gibson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
On Mon, 19 Jan 2026 16:13:35 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Jan 16, 2026 at 10:09:34AM +0100, Herve Codina wrote:
> > Hi David,
> >
> > On Thu, 15 Jan 2026 11:12:49 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > > > This v18 version will add support for
> > > > - metadata in device-tree blobs in order to have a better handling of
> > > > phandles and unresolved references.
> > > > - Addon device-tree blob (successor of device-tree overlay)
> > > > - Import and export symbols feature
> > > > - multiple trees in a addon device-tree blob (i.e. root device tree and
> > > > orphan node tree)
> > >
> > > So, once this patch is applied, the rest of the series pretty much has
> > > to be applied "atomically" - otherwise a version built in the interim
> > > will be lying in saying that it supports v18.
> > >
> > > I therefore suggest moving any changes that *can* be moved before this
> > > patch, should be moved before this patch. That will assist in
> > > reviewing and merging the series piecemeal, rather than as a single
> > > giant blob.
> > >
> > >
> > > Regarding the content itself. It seems like this is a pretty major
> > > change to the dtb format - maybe that would suggest bumping the
> > > version by more than one (e.g. like we went from v3 to v16 in the
> > > past).
> >
> > I see your point.
> >
> > Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
> > related to the generic tag value definition to support those 'unknown tag'
> > could help here.
>
> Having a standard encoding of tag length so unknown tags can be
> skipped is a reasonable idea. I think you do need provision to mark a
> tag as "safe to ignore" or not - e.g. something like FDT_BEGIN_NODE
> could never be safely ignored.
A bit can be used for marking a tag as "safe to ignore if unknown".
I can reduce the bits 30..28 field.
bit 30:
- 0b0: Do not ignore this tag if the tag id is unknown.
If this tag id is unknown an error in the parsing should be reported.
- 0b1: This tag can be safely ignore if its id is unknown. I that case the
tag and its related data are simply skipped.
bits 29..28:
- 0b00: No data
- 0b01: tag followed by 1 cell (u32) data
- 0b10: tag followed by 2 cells (2 x u32) data
- 0b11: Tag is followed by a cell (u32) indicating the size of following
data
Also, it is worth noting that the 0x0....... tag value family can still be
used.
Even if related to "old" tags, if a tag in this family is an unknwown tag,
the parser will report an error (at least because it doesn't know how to
skip the data part).
>
> > As a reminder here, this generic tag value definition consist in:
> > --- 8< ---
> > A tag value is on 32bits. We can define the structure of this value.
> > - bit 31 (msb):
> > - 0: This is not a new kind to tag and so it doesn't follow this definition.
> > All existing tags are in this category
> > - 1: New kind of tag adopting this definition
> >
> > - bits 30..28:
> > tag data length encoding
> > 0b000: No data related to the tag
> > 0b001: 1 data cell (u32) directly follows the tag
> > 0b010: 2 data cells (2 u32) directly follow the tag
> > ...
> > 0b110: 6 data cells (6 u32) directly follow the tag
> > 0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
> > of data available just after this cell (including any padding
> > if needed).
>
> I'd suggesting giving a byte length not including alignment padding.
> That way if you wanted to encode a bytestring in there, you wouldn't
> need a way of encoding the unpadded length in adddition to the
> standard way encoding the padded length.
And so, next tag is always length + sizeof(padding). Next tag is aligned
on 32bits.
>
> > Because this size include some possible padding, its value is a
> > multiple of 4 bytes.
> > The offset of the tag + 4 + size points to the next tag.
> >
> >
> > - bit 27..0
> > tag specific identifier
> > --- 8< ---
> >
> > I mean dtb version v20 could be:
> >
> > - New header size with dt_flags added in the header (if this new field is
> > kept).
> >
> > - Support for the generic tag values and so the notion of 'unknown tag'
> >
> > With that done, everything else added afterward will have no impact on the
> > dtb format itself.
>
> Well... maybe. It's not entirely clear to me whether all the new tags
> can be safely ignored by something that doesn't understand them.
> e.g. a consumer can't safely ignore the tags which give unresolved
> phandle references if it then expects the phandle values in the actual
> property values to be correct.
I would say that it depends on new (future) tags.
For instance, FDT_EXPORT_SYM, the tag used for exported symbols can be ignore
by the bootloader if it doesn't know about this tag.
Indeed, it doesn't need to understand and manipulate this tag. It just needs to
keep it in the dtb passed to the kernel.
> >
> > Only libfdt and dtc will have versions defined at some point with support for
> > some new flags or new keyword.
> >
> > What do you think about this v20 dtb version?
> >
> > >
> > > It would also be nice to have some docs for the new dtb extensions
> > > before or at the same time as this.
> >
> > Yes, the generic tag value definition.
>
> We'd want that, but it's not enough. The specific tag types should be
> documented as well.
Yes they will be documented as soon as they are introduced.
The generic tag value definition is the first step to have in docs to allow
the "skip if unknown" feature.
Best regards,
Hervé
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-19 9:48 ` Herve Codina
@ 2026-01-28 1:49 ` David Gibson
0 siblings, 0 replies; 160+ messages in thread
From: David Gibson @ 2026-01-28 1:49 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 7379 bytes --]
On Mon, Jan 19, 2026 at 10:48:52AM +0100, Herve Codina wrote:
> On Mon, 19 Jan 2026 16:13:35 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Fri, Jan 16, 2026 at 10:09:34AM +0100, Herve Codina wrote:
> > > Hi David,
> > >
> > > On Thu, 15 Jan 2026 11:12:49 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > > > > This v18 version will add support for
> > > > > - metadata in device-tree blobs in order to have a better handling of
> > > > > phandles and unresolved references.
> > > > > - Addon device-tree blob (successor of device-tree overlay)
> > > > > - Import and export symbols feature
> > > > > - multiple trees in a addon device-tree blob (i.e. root device tree and
> > > > > orphan node tree)
> > > >
> > > > So, once this patch is applied, the rest of the series pretty much has
> > > > to be applied "atomically" - otherwise a version built in the interim
> > > > will be lying in saying that it supports v18.
> > > >
> > > > I therefore suggest moving any changes that *can* be moved before this
> > > > patch, should be moved before this patch. That will assist in
> > > > reviewing and merging the series piecemeal, rather than as a single
> > > > giant blob.
> > > >
> > > >
> > > > Regarding the content itself. It seems like this is a pretty major
> > > > change to the dtb format - maybe that would suggest bumping the
> > > > version by more than one (e.g. like we went from v3 to v16 in the
> > > > past).
> > >
> > > I see your point.
> > >
> > > Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
> > > related to the generic tag value definition to support those 'unknown tag'
> > > could help here.
> >
> > Having a standard encoding of tag length so unknown tags can be
> > skipped is a reasonable idea. I think you do need provision to mark a
> > tag as "safe to ignore" or not - e.g. something like FDT_BEGIN_NODE
> > could never be safely ignored.
>
> A bit can be used for marking a tag as "safe to ignore if unknown".
> I can reduce the bits 30..28 field.
>
> bit 30:
> - 0b0: Do not ignore this tag if the tag id is unknown.
> If this tag id is unknown an error in the parsing should be reported.
> - 0b1: This tag can be safely ignore if its id is unknown. I that case the
> tag and its related data are simply skipped.
>
> bits 29..28:
> - 0b00: No data
> - 0b01: tag followed by 1 cell (u32) data
> - 0b10: tag followed by 2 cells (2 x u32) data
> - 0b11: Tag is followed by a cell (u32) indicating the size of following
> data
>
> Also, it is worth noting that the 0x0....... tag value family can still be
> used.
Actually, that's a good point. We can do this more simply: the new
ranges with defined lengths are only used for ignorable tags. If we
need to add new tags which aren't safe to ignore, they go in the 0x0
range, like the existing tags.
> Even if related to "old" tags, if a tag in this family is an unknwown tag,
> the parser will report an error (at least because it doesn't know how to
> skip the data part).
>
> >
> > > As a reminder here, this generic tag value definition consist in:
> > > --- 8< ---
> > > A tag value is on 32bits. We can define the structure of this value.
> > > - bit 31 (msb):
> > > - 0: This is not a new kind to tag and so it doesn't follow this definition.
> > > All existing tags are in this category
> > > - 1: New kind of tag adopting this definition
> > >
> > > - bits 30..28:
> > > tag data length encoding
> > > 0b000: No data related to the tag
> > > 0b001: 1 data cell (u32) directly follows the tag
> > > 0b010: 2 data cells (2 u32) directly follow the tag
> > > ...
> > > 0b110: 6 data cells (6 u32) directly follow the tag
> > > 0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
> > > of data available just after this cell (including any padding
> > > if needed).
> >
> > I'd suggesting giving a byte length not including alignment padding.
> > That way if you wanted to encode a bytestring in there, you wouldn't
> > need a way of encoding the unpadded length in adddition to the
> > standard way encoding the padded length.
>
> And so, next tag is always length + sizeof(padding). Next tag is aligned
> on 32bits.
Exactly. Or to make it clearer that we don't need any additional
information, next tag is at ALIGN_UP(length, FDT_TAG_SIZE). We
already do something like this with with FDT_BEGIN_NODE tags - we
ignore bytes to realign after the node name string.
> > > Because this size include some possible padding, its value is a
> > > multiple of 4 bytes.
> > > The offset of the tag + 4 + size points to the next tag.
> > >
> > >
> > > - bit 27..0
> > > tag specific identifier
> > > --- 8< ---
> > >
> > > I mean dtb version v20 could be:
> > >
> > > - New header size with dt_flags added in the header (if this new field is
> > > kept).
> > >
> > > - Support for the generic tag values and so the notion of 'unknown tag'
> > >
> > > With that done, everything else added afterward will have no impact on the
> > > dtb format itself.
> >
> > Well... maybe. It's not entirely clear to me whether all the new tags
> > can be safely ignored by something that doesn't understand them.
> > e.g. a consumer can't safely ignore the tags which give unresolved
> > phandle references if it then expects the phandle values in the actual
> > property values to be correct.
>
> I would say that it depends on new (future) tags.
Certainly.
> For instance, FDT_EXPORT_SYM, the tag used for exported symbols can be ignore
> by the bootloader if it doesn't know about this tag.
> Indeed, it doesn't need to understand and manipulate this tag. It just needs to
> keep it in the dtb passed to the kernel.
Ow, that's when it gets complicated. Whether a tag is safely
ignorable depends on what the consumer is doing with it. Fixups and
exports can be safely ignored by something just passing it through.
However reference fixups *can't* be safely ignored by something that
will consult phandles, because they might not be correct until the
fixups are applied.
> > > Only libfdt and dtc will have versions defined at some point with support for
> > > some new flags or new keyword.
> > >
> > > What do you think about this v20 dtb version?
> > >
> > > >
> > > > It would also be nice to have some docs for the new dtb extensions
> > > > before or at the same time as this.
> > >
> > > Yes, the generic tag value definition.
> >
> > We'd want that, but it's not enough. The specific tag types should be
> > documented as well.
>
> Yes they will be documented as soon as they are introduced.
>
> The generic tag value definition is the first step to have in docs to allow
> the "skip if unknown" feature.
>
> Best regards,
> Hervé
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-19 5:13 ` David Gibson
2026-01-19 9:48 ` Herve Codina
@ 2026-01-20 20:38 ` Rob Herring
2026-01-29 1:40 ` David Gibson
1 sibling, 1 reply; 160+ messages in thread
From: Rob Herring @ 2026-01-20 20:38 UTC (permalink / raw)
To: David Gibson
Cc: Herve Codina, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
On Sun, Jan 18, 2026 at 11:18 PM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Fri, Jan 16, 2026 at 10:09:34AM +0100, Herve Codina wrote:
> > Hi David,
> >
> > On Thu, 15 Jan 2026 11:12:49 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > > On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > > > This v18 version will add support for
> > > > - metadata in device-tree blobs in order to have a better handling of
> > > > phandles and unresolved references.
> > > > - Addon device-tree blob (successor of device-tree overlay)
> > > > - Import and export symbols feature
> > > > - multiple trees in a addon device-tree blob (i.e. root device tree and
> > > > orphan node tree)
> > >
> > > So, once this patch is applied, the rest of the series pretty much has
> > > to be applied "atomically" - otherwise a version built in the interim
> > > will be lying in saying that it supports v18.
> > >
> > > I therefore suggest moving any changes that *can* be moved before this
> > > patch, should be moved before this patch. That will assist in
> > > reviewing and merging the series piecemeal, rather than as a single
> > > giant blob.
> > >
> > >
> > > Regarding the content itself. It seems like this is a pretty major
> > > change to the dtb format - maybe that would suggest bumping the
> > > version by more than one (e.g. like we went from v3 to v16 in the
> > > past).
> >
> > I see your point.
> >
> > Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
> > related to the generic tag value definition to support those 'unknown tag'
> > could help here.
>
> Having a standard encoding of tag length so unknown tags can be
> skipped is a reasonable idea. I think you do need provision to mark a
> tag as "safe to ignore" or not - e.g. something like FDT_BEGIN_NODE
> could never be safely ignored.
>
> > As a reminder here, this generic tag value definition consist in:
> > --- 8< ---
> > A tag value is on 32bits. We can define the structure of this value.
> > - bit 31 (msb):
> > - 0: This is not a new kind to tag and so it doesn't follow this definition.
> > All existing tags are in this category
> > - 1: New kind of tag adopting this definition
> >
> > - bits 30..28:
> > tag data length encoding
> > 0b000: No data related to the tag
> > 0b001: 1 data cell (u32) directly follows the tag
> > 0b010: 2 data cells (2 u32) directly follow the tag
> > ...
> > 0b110: 6 data cells (6 u32) directly follow the tag
> > 0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
> > of data available just after this cell (including any padding
> > if needed).
>
> I'd suggesting giving a byte length not including alignment padding.
> That way if you wanted to encode a bytestring in there, you wouldn't
> need a way of encoding the unpadded length in adddition to the
> standard way encoding the padded length.
>
> > Because this size include some possible padding, its value is a
> > multiple of 4 bytes.
> > The offset of the tag + 4 + size points to the next tag.
> >
> >
> > - bit 27..0
> > tag specific identifier
> > --- 8< ---
> >
> > I mean dtb version v20 could be:
> >
> > - New header size with dt_flags added in the header (if this new field is
> > kept).
> >
> > - Support for the generic tag values and so the notion of 'unknown tag'
> >
> > With that done, everything else added afterward will have no impact on the
> > dtb format itself.
>
> Well... maybe. It's not entirely clear to me whether all the new tags
> can be safely ignored by something that doesn't understand them.
> e.g. a consumer can't safely ignore the tags which give unresolved
> phandle references if it then expects the phandle values in the actual
> property values to be correct.
I think we'd want some higher level "this is an addon or base DT" than
presence of tags. Maybe that's just the version. Perhaps a new header
field to say this is a base or addon DT. Or both?
Everything in this series intended for the base DT should be safe to
ignore just as __symbols__ (and __local_fixups__ if you add /plugin/)
is safe to ignore. It's only software that understands and wants to
use the new "addons" that needs to understand.
Rob
^ permalink raw reply [flat|nested] 160+ messages in thread
* Re: [RFC PATCH 02/77] Introduce v18 dtb version
2026-01-20 20:38 ` Rob Herring
@ 2026-01-29 1:40 ` David Gibson
0 siblings, 0 replies; 160+ messages in thread
From: David Gibson @ 2026-01-29 1:40 UTC (permalink / raw)
To: Rob Herring
Cc: Herve Codina, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 5287 bytes --]
On Tue, Jan 20, 2026 at 02:38:45PM -0600, Rob Herring wrote:
> On Sun, Jan 18, 2026 at 11:18 PM David Gibson
> <david@gibson.dropbear.id.au> wrote:
> >
> > On Fri, Jan 16, 2026 at 10:09:34AM +0100, Herve Codina wrote:
> > > Hi David,
> > >
> > > On Thu, 15 Jan 2026 11:12:49 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > On Mon, Jan 12, 2026 at 03:18:52PM +0100, Herve Codina wrote:
> > > > > This v18 version will add support for
> > > > > - metadata in device-tree blobs in order to have a better handling of
> > > > > phandles and unresolved references.
> > > > > - Addon device-tree blob (successor of device-tree overlay)
> > > > > - Import and export symbols feature
> > > > > - multiple trees in a addon device-tree blob (i.e. root device tree and
> > > > > orphan node tree)
> > > >
> > > > So, once this patch is applied, the rest of the series pretty much has
> > > > to be applied "atomically" - otherwise a version built in the interim
> > > > will be lying in saying that it supports v18.
> > > >
> > > > I therefore suggest moving any changes that *can* be moved before this
> > > > patch, should be moved before this patch. That will assist in
> > > > reviewing and merging the series piecemeal, rather than as a single
> > > > giant blob.
> > > >
> > > >
> > > > Regarding the content itself. It seems like this is a pretty major
> > > > change to the dtb format - maybe that would suggest bumping the
> > > > version by more than one (e.g. like we went from v3 to v16 in the
> > > > past).
> > >
> > > I see your point.
> > >
> > > Maybe the Rob's idea related to 'unknown tag' and the suggestion I did [1]
> > > related to the generic tag value definition to support those 'unknown tag'
> > > could help here.
> >
> > Having a standard encoding of tag length so unknown tags can be
> > skipped is a reasonable idea. I think you do need provision to mark a
> > tag as "safe to ignore" or not - e.g. something like FDT_BEGIN_NODE
> > could never be safely ignored.
> >
> > > As a reminder here, this generic tag value definition consist in:
> > > --- 8< ---
> > > A tag value is on 32bits. We can define the structure of this value.
> > > - bit 31 (msb):
> > > - 0: This is not a new kind to tag and so it doesn't follow this definition.
> > > All existing tags are in this category
> > > - 1: New kind of tag adopting this definition
> > >
> > > - bits 30..28:
> > > tag data length encoding
> > > 0b000: No data related to the tag
> > > 0b001: 1 data cell (u32) directly follows the tag
> > > 0b010: 2 data cells (2 u32) directly follow the tag
> > > ...
> > > 0b110: 6 data cells (6 u32) directly follow the tag
> > > 0b111: Tag is followed by a cell (u32) indicating the size (in bytes)
> > > of data available just after this cell (including any padding
> > > if needed).
> >
> > I'd suggesting giving a byte length not including alignment padding.
> > That way if you wanted to encode a bytestring in there, you wouldn't
> > need a way of encoding the unpadded length in adddition to the
> > standard way encoding the padded length.
> >
> > > Because this size include some possible padding, its value is a
> > > multiple of 4 bytes.
> > > The offset of the tag + 4 + size points to the next tag.
> > >
> > >
> > > - bit 27..0
> > > tag specific identifier
> > > --- 8< ---
> > >
> > > I mean dtb version v20 could be:
> > >
> > > - New header size with dt_flags added in the header (if this new field is
> > > kept).
> > >
> > > - Support for the generic tag values and so the notion of 'unknown tag'
> > >
> > > With that done, everything else added afterward will have no impact on the
> > > dtb format itself.
> >
> > Well... maybe. It's not entirely clear to me whether all the new tags
> > can be safely ignored by something that doesn't understand them.
> > e.g. a consumer can't safely ignore the tags which give unresolved
> > phandle references if it then expects the phandle values in the actual
> > property values to be correct.
>
> I think we'd want some higher level "this is an addon or base DT" than
> presence of tags. Maybe that's just the version. Perhaps a new header
> field to say this is a base or addon DT. Or both?
I think Herve's flags proposed flags field does that. I tend to
prefer the idea of using new and different magic numbers for the
variant forms though - makes it really clear that they're a different
thing from a "normal" fdt.
>
> Everything in this series intended for the base DT should be safe to
> ignore just as __symbols__ (and __local_fixups__ if you add /plugin/)
> is safe to ignore.
That kind of depends what you're doing with the DT. If you need to do
phandle lookups, you can't safely ignore the fixups.
> It's only software that understands and wants to
> use the new "addons" that needs to understand.
>
> Rob
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* [RFC PATCH 03/77] libfdt: Introduce fdt_next_tag_full() and use it in fdt_next_tag()
2026-01-12 14:18 [RFC PATCH 00/77] Add support for dtb metadata and addon device-trees Herve Codina
2026-01-12 14:18 ` [RFC PATCH 01/77] checks: Use consistent type for strspn() returned value Herve Codina
2026-01-12 14:18 ` [RFC PATCH 02/77] Introduce v18 dtb version Herve Codina
@ 2026-01-12 14:18 ` Herve Codina
2026-01-15 0:17 ` David Gibson
2026-01-12 14:18 ` [RFC PATCH 04/77] dtc: Allow to use data_append_markers() out of data.c Herve Codina
` (76 subsequent siblings)
79 siblings, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-12 14:18 UTC (permalink / raw)
To: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli,
Thomas Petazzoni, Herve Codina
In v18 dtb new tags are added. Prepare libfdt to handle those new tags.
Keep fdt_next_tag() handling only existing tags and introduce
fdt_next_tag_full() to handle new tags.
fdt_next_tag() uses fdt_next_tag_full() but it will filter out new tags
when they are introduced to have those new tags transparent for existing
fdt_next_tag() callers.
Code that will need to handle those new tags will use explicitly
fdt_next_tag_full() to have access to them when they need to.
No new tags have been introduced yet and modifications done here prepare
their introduction.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
libfdt/fdt.c | 35 ++++++++++++++++++++++++++++++++++-
libfdt/libfdt.h | 18 ++++++++++++++++++
libfdt/version.lds | 1 +
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/libfdt/fdt.c b/libfdt/fdt.c
index 95f644c..ce051a0 100644
--- a/libfdt/fdt.c
+++ b/libfdt/fdt.c
@@ -159,7 +159,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
return fdt_offset_ptr_(fdt, offset);
}
-uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+uint32_t fdt_next_tag_full(const void *fdt, int startoffset, int *nextoffset)
{
const fdt32_t *tagp, *lenp;
uint32_t tag, len, sum;
@@ -220,6 +220,39 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
return tag;
}
+uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
+{
+ uint32_t tag, tmp_tag;
+ int tmp_offset, tmp_next;
+
+ /* Retrieve next tag */
+ tag = fdt_next_tag_full(fdt, startoffset, nextoffset);
+
+ /* Look at next one to see what we need to do */
+ tmp_next = *nextoffset;
+ do {
+ tmp_offset = tmp_next;
+ tmp_tag = fdt_next_tag_full(fdt, tmp_offset, &tmp_next);
+ switch (tmp_tag) {
+ case FDT_BEGIN_NODE:
+ case FDT_END_NODE:
+ case FDT_PROP:
+ case FDT_NOP:
+ case FDT_END:
+ /* Next tag is not new tag introduced in v18 -> Ok */
+ *nextoffset = tmp_offset;
+ return tag;
+
+ default:
+ break;
+ }
+ } while (1);
+
+ /* We shouldn't reach this code */
+ *nextoffset = -FDT_ERR_BADSTRUCTURE;
+ return FDT_END;
+}
+
int fdt_check_node_offset_(const void *fdt, int offset)
{
if (!can_assume(VALID_INPUT)
diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
index c5cd35d..d1a9cd5 100644
--- a/libfdt/libfdt.h
+++ b/libfdt/libfdt.h
@@ -154,6 +154,24 @@ static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
*/
uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
+/**
+ * fdt_next_tag_full - get next tag in the device tree without any filtering
+ * @fdt: Pointer to the device tree blob
+ * @offset: Offset within the blob to start searching
+ * @nextoffset: Pointer to variable to store the offset of the next tag
+ *
+ * fdt_next_tag_full() returns the tag type of the next tag in the device tree
+ * blob starting from the given @offset. If @nextoffset is non-NULL, it will
+ * be set to the offset immediately following the tag.
+ * fdt_next_tag() can return only a subset of all possible tags performing some
+ * internal filtering. fdt_next_tag_full() doesn't perform this filtering.
+ *
+ * returns:
+ * the tag type (FDT_BEGIN_NODE, FDT_END_NODE, FDT_PROP, FDT_NOP, FDT_END),
+ * FDT_END, if offset is out of bounds
+ */
+uint32_t fdt_next_tag_full(const void *fdt, int offset, int *nextoffset);
+
/*
* External helpers to access words from a device tree blob. They're built
* to work even with unaligned pointers on platforms (such as ARMv5) that don't
diff --git a/libfdt/version.lds b/libfdt/version.lds
index cbfef54..7e2dde2 100644
--- a/libfdt/version.lds
+++ b/libfdt/version.lds
@@ -52,6 +52,7 @@ LIBFDT_1.2 {
fdt_strerror;
fdt_offset_ptr;
fdt_next_tag;
+ fdt_next_tag_full;
fdt_appendprop;
fdt_create_empty_tree;
fdt_first_property_offset;
--
2.52.0
^ permalink raw reply related [flat|nested] 160+ messages in thread* Re: [RFC PATCH 03/77] libfdt: Introduce fdt_next_tag_full() and use it in fdt_next_tag()
2026-01-12 14:18 ` [RFC PATCH 03/77] libfdt: Introduce fdt_next_tag_full() and use it in fdt_next_tag() Herve Codina
@ 2026-01-15 0:17 ` David Gibson
0 siblings, 0 replies; 160+ messages in thread
From: David Gibson @ 2026-01-15 0:17 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 5165 bytes --]
On Mon, Jan 12, 2026 at 03:18:53PM +0100, Herve Codina wrote:
> In v18 dtb new tags are added. Prepare libfdt to handle those new tags.
>
> Keep fdt_next_tag() handling only existing tags and introduce
> fdt_next_tag_full() to handle new tags.
Ugh, that's super ugly.
My first inclination is to say that if you're using the low-level
fdt_next_tag() interface, it's your responsibility to check the
version first - fdt_next_tag() should return... the next tag... and
it's the caller's problem if it doesn't know about it.
Maybe that breaks some real user too badly, though. The other
approach would be to use the symbol versioning we already have: we
bump the libfdt version, and have different versions of fdt_next_tag()
depending on the version you're using.
Btw, once you generate a dtb with new tags, its last_compat_version
must become v18 as well as it's version - tools need to be aware of
the new tags.
>
> fdt_next_tag() uses fdt_next_tag_full() but it will filter out new tags
> when they are introduced to have those new tags transparent for existing
> fdt_next_tag() callers.
>
> Code that will need to handle those new tags will use explicitly
> fdt_next_tag_full() to have access to them when they need to.
>
> No new tags have been introduced yet and modifications done here prepare
> their introduction.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> libfdt/fdt.c | 35 ++++++++++++++++++++++++++++++++++-
> libfdt/libfdt.h | 18 ++++++++++++++++++
> libfdt/version.lds | 1 +
> 3 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/libfdt/fdt.c b/libfdt/fdt.c
> index 95f644c..ce051a0 100644
> --- a/libfdt/fdt.c
> +++ b/libfdt/fdt.c
> @@ -159,7 +159,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, unsigned int len)
> return fdt_offset_ptr_(fdt, offset);
> }
>
> -uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
> +uint32_t fdt_next_tag_full(const void *fdt, int startoffset, int *nextoffset)
> {
> const fdt32_t *tagp, *lenp;
> uint32_t tag, len, sum;
> @@ -220,6 +220,39 @@ uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
> return tag;
> }
>
> +uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
> +{
> + uint32_t tag, tmp_tag;
> + int tmp_offset, tmp_next;
> +
> + /* Retrieve next tag */
> + tag = fdt_next_tag_full(fdt, startoffset, nextoffset);
> +
> + /* Look at next one to see what we need to do */
> + tmp_next = *nextoffset;
> + do {
> + tmp_offset = tmp_next;
> + tmp_tag = fdt_next_tag_full(fdt, tmp_offset, &tmp_next);
> + switch (tmp_tag) {
> + case FDT_BEGIN_NODE:
> + case FDT_END_NODE:
> + case FDT_PROP:
> + case FDT_NOP:
> + case FDT_END:
> + /* Next tag is not new tag introduced in v18 -> Ok */
> + *nextoffset = tmp_offset;
> + return tag;
> +
> + default:
> + break;
> + }
> + } while (1);
> +
> + /* We shouldn't reach this code */
> + *nextoffset = -FDT_ERR_BADSTRUCTURE;
> + return FDT_END;
> +}
> +
> int fdt_check_node_offset_(const void *fdt, int offset)
> {
> if (!can_assume(VALID_INPUT)
> diff --git a/libfdt/libfdt.h b/libfdt/libfdt.h
> index c5cd35d..d1a9cd5 100644
> --- a/libfdt/libfdt.h
> +++ b/libfdt/libfdt.h
> @@ -154,6 +154,24 @@ static inline void *fdt_offset_ptr_w(void *fdt, int offset, int checklen)
> */
> uint32_t fdt_next_tag(const void *fdt, int offset, int *nextoffset);
>
> +/**
> + * fdt_next_tag_full - get next tag in the device tree without any filtering
> + * @fdt: Pointer to the device tree blob
> + * @offset: Offset within the blob to start searching
> + * @nextoffset: Pointer to variable to store the offset of the next tag
> + *
> + * fdt_next_tag_full() returns the tag type of the next tag in the device tree
> + * blob starting from the given @offset. If @nextoffset is non-NULL, it will
> + * be set to the offset immediately following the tag.
> + * fdt_next_tag() can return only a subset of all possible tags performing some
> + * internal filtering. fdt_next_tag_full() doesn't perform this filtering.
> + *
> + * returns:
> + * the tag type (FDT_BEGIN_NODE, FDT_END_NODE, FDT_PROP, FDT_NOP, FDT_END),
> + * FDT_END, if offset is out of bounds
> + */
> +uint32_t fdt_next_tag_full(const void *fdt, int offset, int *nextoffset);
> +
> /*
> * External helpers to access words from a device tree blob. They're built
> * to work even with unaligned pointers on platforms (such as ARMv5) that don't
> diff --git a/libfdt/version.lds b/libfdt/version.lds
> index cbfef54..7e2dde2 100644
> --- a/libfdt/version.lds
> +++ b/libfdt/version.lds
> @@ -52,6 +52,7 @@ LIBFDT_1.2 {
> fdt_strerror;
> fdt_offset_ptr;
> fdt_next_tag;
> + fdt_next_tag_full;
> fdt_appendprop;
> fdt_create_empty_tree;
> fdt_first_property_offset;
> --
> 2.52.0
>
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* [RFC PATCH 04/77] dtc: Allow to use data_append_markers() out of data.c
2026-01-12 14:18 [RFC PATCH 00/77] Add support for dtb metadata and addon device-trees Herve Codina
` (2 preceding siblings ...)
2026-01-12 14:18 ` [RFC PATCH 03/77] libfdt: Introduce fdt_next_tag_full() and use it in fdt_next_tag() Herve Codina
@ 2026-01-12 14:18 ` Herve Codina
2026-01-15 0:18 ` David Gibson
2026-01-12 14:18 ` [RFC PATCH 05/77] fdtdump: Change FDT_PROP prob handling to ease future addition Herve Codina
` (75 subsequent siblings)
79 siblings, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-12 14:18 UTC (permalink / raw)
To: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli,
Thomas Petazzoni, Herve Codina
With meta-data available in dtb, markers can be set as soon as a dtb is
parsed. This will be done in flattree.c using data_append_markers().
Prepare this usage allowing this function to be used out of data.c
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
data.c | 2 +-
dtc.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/data.c b/data.c
index 5b25aa0..11b2169 100644
--- a/data.c
+++ b/data.c
@@ -127,7 +127,7 @@ struct data data_insert_at_marker(struct data d, struct marker *m,
return d;
}
-static struct data data_append_markers(struct data d, struct marker *m)
+struct data data_append_markers(struct data d, struct marker *m)
{
struct marker **mp = &d.markers;
diff --git a/dtc.h b/dtc.h
index 186caad..3bbd97e 100644
--- a/dtc.h
+++ b/dtc.h
@@ -187,6 +187,7 @@ struct data data_insert_data(struct data d, struct marker *m, struct data old);
struct marker *alloc_marker(unsigned int offset, enum markertype type,
char *ref);
struct data data_add_marker(struct data d, enum markertype type, char *ref);
+struct data data_append_markers(struct data d, struct marker *m);
bool data_is_one_string(struct data d);
--
2.52.0
^ permalink raw reply related [flat|nested] 160+ messages in thread* Re: [RFC PATCH 04/77] dtc: Allow to use data_append_markers() out of data.c
2026-01-12 14:18 ` [RFC PATCH 04/77] dtc: Allow to use data_append_markers() out of data.c Herve Codina
@ 2026-01-15 0:18 ` David Gibson
0 siblings, 0 replies; 160+ messages in thread
From: David Gibson @ 2026-01-15 0:18 UTC (permalink / raw)
To: Herve Codina
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ayush Singh,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
On Mon, Jan 12, 2026 at 03:18:54PM +0100, Herve Codina wrote:
> With meta-data available in dtb, markers can be set as soon as a dtb is
> parsed. This will be done in flattree.c using data_append_markers().
>
> Prepare this usage allowing this function to be used out of data.c
Trivial enough I'd suggest folding it into the patch that needs to use
data_append_markers() elsewhere.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> data.c | 2 +-
> dtc.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/data.c b/data.c
> index 5b25aa0..11b2169 100644
> --- a/data.c
> +++ b/data.c
> @@ -127,7 +127,7 @@ struct data data_insert_at_marker(struct data d, struct marker *m,
> return d;
> }
>
> -static struct data data_append_markers(struct data d, struct marker *m)
> +struct data data_append_markers(struct data d, struct marker *m)
> {
> struct marker **mp = &d.markers;
>
> diff --git a/dtc.h b/dtc.h
> index 186caad..3bbd97e 100644
> --- a/dtc.h
> +++ b/dtc.h
> @@ -187,6 +187,7 @@ struct data data_insert_data(struct data d, struct marker *m, struct data old);
> struct marker *alloc_marker(unsigned int offset, enum markertype type,
> char *ref);
> struct data data_add_marker(struct data d, enum markertype type, char *ref);
> +struct data data_append_markers(struct data d, struct marker *m);
>
> bool data_is_one_string(struct data d);
>
> --
> 2.52.0
>
>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* [RFC PATCH 05/77] fdtdump: Change FDT_PROP prob handling to ease future addition
2026-01-12 14:18 [RFC PATCH 00/77] Add support for dtb metadata and addon device-trees Herve Codina
` (3 preceding siblings ...)
2026-01-12 14:18 ` [RFC PATCH 04/77] dtc: Allow to use data_append_markers() out of data.c Herve Codina
@ 2026-01-12 14:18 ` Herve Codina
2026-01-12 15:41 ` Ayush Singh
2026-01-12 14:18 ` [RFC PATCH 06/77] Add support for FDT_REF_LOCAL dtb tag Herve Codina
` (74 subsequent siblings)
79 siblings, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-12 14:18 UTC (permalink / raw)
To: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli,
Thomas Petazzoni, Herve Codina
In order to ease future tags addition, perform operation related to
FDT_PROP when the tag is explicitly FDT_PROP instead of relying to a
kind of default value case.
Handle the FDT_PROP tag exactly in the same way as it is done for
other tags.
No functional modification.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
fdtdump.c | 34 ++++++++++++++++++----------------
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/fdtdump.c b/fdtdump.c
index ec25edf..95a2274 100644
--- a/fdtdump.c
+++ b/fdtdump.c
@@ -129,23 +129,25 @@ static void dump_blob(void *blob, bool debug)
continue;
}
- if (tag != FDT_PROP) {
- fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
- break;
+ if (tag == FDT_PROP) {
+ sz = fdt32_to_cpu(GET_CELL(p));
+ s = p_strings + fdt32_to_cpu(GET_CELL(p));
+ if (version < 16 && sz >= 8)
+ p = PALIGN(p, 8);
+ t = p;
+
+ p = PALIGN(p + sz, 4);
+
+ dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
+ dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
+ printf("%*s%s", depth * shift, "", s);
+ utilfdt_print_data(t, sz);
+ printf(";\n");
+ continue;
}
- sz = fdt32_to_cpu(GET_CELL(p));
- s = p_strings + fdt32_to_cpu(GET_CELL(p));
- if (version < 16 && sz >= 8)
- p = PALIGN(p, 8);
- t = p;
-
- p = PALIGN(p + sz, 4);
-
- dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
- dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
- printf("%*s%s", depth * shift, "", s);
- utilfdt_print_data(t, sz);
- printf(";\n");
+
+ fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
+ break;
}
}
--
2.52.0
^ permalink raw reply related [flat|nested] 160+ messages in thread* Re: [RFC PATCH 05/77] fdtdump: Change FDT_PROP prob handling to ease future addition
2026-01-12 14:18 ` [RFC PATCH 05/77] fdtdump: Change FDT_PROP prob handling to ease future addition Herve Codina
@ 2026-01-12 15:41 ` Ayush Singh
2026-01-15 0:28 ` David Gibson
0 siblings, 1 reply; 160+ messages in thread
From: Ayush Singh @ 2026-01-12 15:41 UTC (permalink / raw)
To: Herve Codina, David Gibson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
On 1/12/26 7:48 PM, Herve Codina wrote:
> In order to ease future tags addition, perform operation related to
> FDT_PROP when the tag is explicitly FDT_PROP instead of relying to a
> kind of default value case.
>
> Handle the FDT_PROP tag exactly in the same way as it is done for
> other tags.
>
> No functional modification.
>
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
> fdtdump.c | 34 ++++++++++++++++++----------------
> 1 file changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/fdtdump.c b/fdtdump.c
> index ec25edf..95a2274 100644
> --- a/fdtdump.c
> +++ b/fdtdump.c
> @@ -129,23 +129,25 @@ static void dump_blob(void *blob, bool debug)
> continue;
> }
>
> - if (tag != FDT_PROP) {
> - fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
> - break;
> + if (tag == FDT_PROP) {
> + sz = fdt32_to_cpu(GET_CELL(p));
> + s = p_strings + fdt32_to_cpu(GET_CELL(p));
> + if (version < 16 && sz >= 8)
> + p = PALIGN(p, 8);
> + t = p;
> +
> + p = PALIGN(p + sz, 4);
> +
> + dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
> + dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
> + printf("%*s%s", depth * shift, "", s);
> + utilfdt_print_data(t, sz);
> + printf(";\n");
> + continue;
> }
> - sz = fdt32_to_cpu(GET_CELL(p));
> - s = p_strings + fdt32_to_cpu(GET_CELL(p));
> - if (version < 16 && sz >= 8)
> - p = PALIGN(p, 8);
> - t = p;
> -
> - p = PALIGN(p + sz, 4);
> -
> - dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
> - dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
> - printf("%*s%s", depth * shift, "", s);
> - utilfdt_print_data(t, sz);
> - printf(";\n");
> +
> + fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
> + break;
> }
> }
>
This seems reasonable refactor independently from the rest of the patch
series.
Reviewed-by: Ayush Singh <ayush@beagleboard.org>
^ permalink raw reply [flat|nested] 160+ messages in thread* Re: [RFC PATCH 05/77] fdtdump: Change FDT_PROP prob handling to ease future addition
2026-01-12 15:41 ` Ayush Singh
@ 2026-01-15 0:28 ` David Gibson
0 siblings, 0 replies; 160+ messages in thread
From: David Gibson @ 2026-01-15 0:28 UTC (permalink / raw)
To: Ayush Singh
Cc: Herve Codina, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, devicetree-compiler, devicetree, linux-kernel,
devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli, Thomas Petazzoni
[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]
On Mon, Jan 12, 2026 at 09:11:52PM +0530, Ayush Singh wrote:
> On 1/12/26 7:48 PM, Herve Codina wrote:
>
> > In order to ease future tags addition, perform operation related to
> > FDT_PROP when the tag is explicitly FDT_PROP instead of relying to a
> > kind of default value case.
> >
> > Handle the FDT_PROP tag exactly in the same way as it is done for
> > other tags.
> >
> > No functional modification.
> >
> > Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> > ---
> > fdtdump.c | 34 ++++++++++++++++++----------------
> > 1 file changed, 18 insertions(+), 16 deletions(-)
> >
> > diff --git a/fdtdump.c b/fdtdump.c
> > index ec25edf..95a2274 100644
> > --- a/fdtdump.c
> > +++ b/fdtdump.c
> > @@ -129,23 +129,25 @@ static void dump_blob(void *blob, bool debug)
> > continue;
> > }
> > - if (tag != FDT_PROP) {
> > - fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
> > - break;
> > + if (tag == FDT_PROP) {
> > + sz = fdt32_to_cpu(GET_CELL(p));
> > + s = p_strings + fdt32_to_cpu(GET_CELL(p));
> > + if (version < 16 && sz >= 8)
> > + p = PALIGN(p, 8);
> > + t = p;
> > +
> > + p = PALIGN(p + sz, 4);
> > +
> > + dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
> > + dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
> > + printf("%*s%s", depth * shift, "", s);
> > + utilfdt_print_data(t, sz);
> > + printf(";\n");
> > + continue;
> > }
> > - sz = fdt32_to_cpu(GET_CELL(p));
> > - s = p_strings + fdt32_to_cpu(GET_CELL(p));
> > - if (version < 16 && sz >= 8)
> > - p = PALIGN(p, 8);
> > - t = p;
> > -
> > - p = PALIGN(p + sz, 4);
> > -
> > - dumpf("%04"PRIxPTR": string: %s\n", (uintptr_t)s - blob_off, s);
> > - dumpf("%04"PRIxPTR": value\n", (uintptr_t)t - blob_off);
> > - printf("%*s%s", depth * shift, "", s);
> > - utilfdt_print_data(t, sz);
> > - printf(";\n");
> > +
> > + fprintf(stderr, "%*s ** Unknown tag 0x%08"PRIx32"\n", depth * shift, "", tag);
> > + break;
> > }
> > }
>
>
> This seems reasonable refactor independently from the rest of the patch
> series.
Agreed. Merged.
> Reviewed-by: Ayush Singh <ayush@beagleboard.org>
--
David Gibson (he or they) | 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 160+ messages in thread
* [RFC PATCH 06/77] Add support for FDT_REF_LOCAL dtb tag
2026-01-12 14:18 [RFC PATCH 00/77] Add support for dtb metadata and addon device-trees Herve Codina
` (4 preceding siblings ...)
2026-01-12 14:18 ` [RFC PATCH 05/77] fdtdump: Change FDT_PROP prob handling to ease future addition Herve Codina
@ 2026-01-12 14:18 ` Herve Codina
2026-01-13 19:22 ` Rob Herring
2026-01-12 14:18 ` [RFC PATCH 07/77] livetree: Improve get_node_by_phandle() Herve Codina
` (73 subsequent siblings)
79 siblings, 1 reply; 160+ messages in thread
From: Herve Codina @ 2026-01-12 14:18 UTC (permalink / raw)
To: David Gibson, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Ayush Singh, Geert Uytterhoeven, devicetree-compiler, devicetree,
linux-kernel, devicetree-spec, Hui Pu, Ian Ray, Luca Ceresoli,
Thomas Petazzoni, Herve Codina
FDT_REF_LOCAL dtb tag is a meta-data tag attached to a property.
It indicates that the property defined before this tag (FDT_PROP) uses a
phandle value and the node related to this phandle value is local (i.e.
the node is present in the device-tree blob).
It is followed by one value:
- offset (32bit):
Offset in the property data where the phandle is available.
Example:
FDT_PROP 0x00000008 xxxxxxxx 0xca 0xfe 0xde 0xca 0x01 0x02 0x03 0x04
FDT_REF_LOCAL 0x00000004
This means that at the offset 4 of the property data, the value
(0x01020304) is a phandle and the related node is available in the
dtb.
This is what is encoded in the dtb when the related dts has a property
with the value set to <0xcafedeca &foo> with 'foo' a reference to an
existing node where the phandle value is 0x01020304.
If several local phandles are used in the property data, several
FDT_REF_LOCAL are present after the FDT_PROP tag. Each of them points
with its offset value to the position of one phandle.
For instance, if a first property with 8 bytes of data has a phandle
value at offset 4 and a second property with 16 bytes of data has
phandle values at offset 0 and 8, the following tags sequence is
present:
FDT_PROP 0x00000008 xxxxxxxx <data bytes>
FDT_REF_LOCAL 0x00000004
FDT_PROP 0x00000010 xxxxxxxx <data bytes>
FDT_REF_LOCAL 0x00000000
FDT_REF_LOCAL 0x00000008
Add support for this new dtb tag.
Suggested-by: David Gibson <david@gibson.dropbear.id.au>
Link: https://lore.kernel.org/all/aL-2fmYsbexEtpNp@zatzit/
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
data.c | 1 +
dtc.h | 1 +
fdtdump.c | 14 +++++++++++++-
flattree.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++-
libfdt/fdt.c | 24 ++++++++++++++++++++++--
libfdt/fdt.h | 1 +
6 files changed, 84 insertions(+), 4 deletions(-)
diff --git a/data.c b/data.c
index 11b2169..9bae704 100644
--- a/data.c
+++ b/data.c
@@ -288,6 +288,7 @@ struct marker *alloc_marker(unsigned int offset, enum markertype type,
m->type = type;
m->ref = ref;
m->next = NULL;
+ m->is_local = 0;
return m;
}
diff --git a/dtc.h b/dtc.h
index