Re: [RFC PATCH 02/77] Introduce v18 dtb version

--1FEfLb+vw8NAWD2h
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 20, 2026 at 02:38:45PM -0600, Rob Herring wrote:
> On Sun, Jan 18, 2026 at 11:18=E2=80=AFPM David Gibson
> <[email protected]> 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 <[email protected]> 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 handli=
ng 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 t=
ree 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 inter=
im
> > > > will be lying in saying that it supports v18.
> > > >
> > > > I therefore suggest moving any changes that *can* be moved before t=
his
> > > > 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 di=
d [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 b=
ytes)
> > >             of data available just after this cell (including any pad=
ding
> > >             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 fie=
ld is
> > >    kept).
> > >
> > >  - Support for the generic tag values and so the notion of 'unknown t=
ag'
> > >
> > > With that done, everything else added afterward will have no impact o=
n 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.
>=20
> 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.

>=20
> 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.
>=20
> Rob
>=20

--=20
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

--1FEfLb+vw8NAWD2h
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAml6unwACgkQzQJF27ox
2GdmSw/5AW8iC48H1xchqCaR6Zhi2KtjEp0kEzZJdnEzWPP/wDXuqKRfjK4Nd42I
XQ1REscNGpoejfhR5DXw3KCVuftobWF90wn+h3WGfux25JIU2R5ZSYDkXDYuoOLt
ku2YOzWZpGtDnM7BAna2W/08pRkYXI5yArwrJuM7aKGnZ0yxvJc5dnF5ZFEaMmDr
g/6DZOneROTU3StuW7laOqEWZfHjgLDV2duLwe4CI+TyCjMA2sHQprDaKDtHq4AW
ZW1kx2Lc6ZBlkLkXrLGOaTkcDfIn5RYCr8fKkL1kMvDFFPCcUOUIM225Cr1VsvMT
XLYXQWIh4kVKMSiwMNAtcEprBQl4HzxwrrHltXMT7vHvwM/74EASqaxAUio5BtIn
EjeBYmnpdgrp2qX1L3O7/zKxl1uZ8+4BXKwl7iwP9lmTuh/40jJKQdLkPJCbcfYO
L/HZufTpzBUDyc5/vFowONhoh6gZdSBuzjo4SJlGaVTXVtNbxeLsq9Kw+9uIc35T
eMjUeYJ9CELLw9+WUlvJSRZ87ANOOIML069F9Tcgo5Ep2Xd5IXLvxUBgpiFjM3AB
XvsDoWIatSIGr4wRotYoEwO2RoRZvyYsY5EbXs4Abjs7oUV1+xfhsVwjZUQ+o6zO
A8wsVFI9Vkq8a4ar/mAICpb73EcEbqjkf+v2mH0NjKv4DZYZncw=
=z+Rj
-----END PGP SIGNATURE-----

--1FEfLb+vw8NAWD2h--