Re: [RFC PATCH 00/15] Add support for structured tags and v18 dtb version

David Gibson
2026-03-12T11:13:30Z

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

On Thu, Mar 12, 2026 at 08:54:00AM +0100, Herve Codina wrote:
> Hi David,
>
> On Tue, 10 Feb 2026 18:33:28 +0100
> Herve Codina <herve.codina@bootlin.com> wrote:
>
> > Recently, I sent a RFC series related to support for metadata and addon
> > device-trees [1].
> >
> > During the discussion the concept of structured tags and "unknown" tags
> > emerged as well as the need to have them handled as a prerequisite of
> > support for metadata and addon.
> >
> > The conclusion was the need for a new dtb version (v18) with support
> > for:
> > - Structured tags and based on them, "unknown" tags.
> > Those structured tags allow to have an standardized definition of
> > tags with the capability of skipping a tag and its related data
> > when a "unknown" tag is incountered by a given version of libfdt,
> > dtc and tools. Those "unknown" tags are tags defined in future
> > versions. Even if they exact meaning is unknown for an 'old'
> > version, they structure is understood and the 'old' version can skip
> > them without any errors if allowed.
> >
> > - Flags in the dtb header (dt_flags).
> > The goal of this field is to have a placeholder to specify the
> > type of dtb we are dealing with. For instance, addons dtb will set a
> > flag in this placeholder
> >
> > - A last compatible version for writing purpose.
> > The goal of the new dtb header field (last_comp_version_w) is to
> > disable globally any modification. It works similarly to
> > last_comp_version but for modification. It can be used to avoid any
> > modification that could be done by an 'old' version and could lead
> > to inconsistencies between the modification itself and some
> > "unknown" tags.
> >
> > This RFC series implements those features and leads to the v18 dtb
> > version.
>
> I sent this series a month ago.
>
> I know some patches have been applied but what's the plan for the remaining
> ones?

Get to them as time permits, which I do not expect to be soon.

> Is there anything I can do to help move things forward?

Usher forth a world where small projects get sufficient support to
have apprentice maintainers? Other than that, not really.

> Let me know if you want some rebase and/or modification and so a new version
> of the series or if you need anything else that can help in moving forward.

I will when I can.

--
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 --]