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

--d439fW6Annuy2nfv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 12, 2026 at 08:54:00AM +0100, Herve Codina wrote:
> Hi David,
>=20
> On Tue, 10 Feb 2026 18:33:28 +0100
> Herve Codina <[email protected]> wrote:
>=20
> > Recently, I sent a RFC series related to support for metadata and addon
> > device-trees [1].
> >=20
> > 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.
> >=20
> > 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.
> >=20
> >   - 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
> >=20
> >   - 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.
> >=20
> > This RFC series implements those features and leads to the v18 dtb
> > version.
>=20
> I sent this series a month ago.
>=20
> I know some patches have been applied but what's the plan for the remaini=
ng
> 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 vers=
ion
> of the series or if you need anything else that can help in moving forwar=
d.

I will when I can.

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

--d439fW6Annuy2nfv
Content-Type: application/pgp-signature; name=signature.asc

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

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmmyk6oACgkQzQJF27ox
2GfnPw//RpwvbzMuQROnh5UoDdsdrkZWylGx2xKuoMVMg0aMpnRBDMJ54FZQ9OZx
zcJUjdqeuhb4LxUtGwZmmjo6Ab+WonINGFIZmGURXzBQrFTu2tWa2QVsAz7XXBe0
7LBcj1YaadQe4cgZS/xhr5aDz1efJhKwWI2CNi+0xWajNdt7wX0Wsi+jMy2CLnDr
VTkDmCwzQ3OWlVFaZQ99e/hL1JhdywEVtBCCEeinLZwYLy7+IA7fFfHTsDGbvmaO
obsIx6nKKE8YWk71J72scdDeajdngmKOzW9xuKCtWcTKMPO0RZUfkdz262rX2isf
8dExCWERYXr0M/nmLnCu1tHU7kDTH0AF7sRzaugTwrupG6MOI5g0ivK3iWX2yBTR
KDfzcDkMV/BoHH2OaA1Sc0DUX3oCAXtXN51p2PhotZKNtDNOzdYrK/2u4P89GSjt
YtVkvWC6bV4bh5JDgnSLKGzL3ys6r/nWhDnmZrbeNPUfo4uWa/QHQ57fhgdgO0x/
zJv+GB0MOOhJlR1jajYDXm2o7UAr5ehV1ZnT9XpXaoactOnzkQG3uTrQWu9ibB6e
TYnVQGk9zkzzFMFjq7/uvFNc2kaxDRoQcesHaOBh4cDu40FRDbK6TJ5uYU1MvwgI
W/3GaSqhX5IUZHPuDD4++rJVkjGG6Jf2Q6mshVwCvciI06OWa88=
=XoO0
-----END PGP SIGNATURE-----

--d439fW6Annuy2nfv--