Re: [RFC PATCH 29/77] Add support for FDT_EXPORT_SYM_REF dtb tag

David Gibson <[email protected]> Thu, 29 Jan 2026 12:36:51 +1100
Newsgroups org.kernel.vger.devicetree-spec,org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <aXq5s-XdN79YzOHF@zatzit>
--w/oBFm/TrS5PBwNI
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 19, 2026 at 04:46:28PM +0100, Herve Codina wrote:
> Hi David,
>=20
> On Thu, 15 Jan 2026 17:25:58 +1100
> David Gibson <[email protected]> wrote:
>=20
> > On Mon, Jan 12, 2026 at 03:19:19PM +0100, Herve Codina wrote:
> > > The FDT_EXPORT_SYM_REF dtb tag is similar to the FDT_EXPORT_SYM tag
> > > except that it identifies a reference to an external phandle. The node
> > > referenced by the phandle is not present in the device-tree blob.
> > >=20
> > > The FDT_EXPORT_SYM_REF dtb tag is a meta-data tag defining an exported
> > > symbol. It can be present in a node bloc meaning that a symbol is
> > > exported at this node level. The node pointed to by this symbol is no=
t a
> > > local node (i.e. the node is not present in the device-tree blob.). T=
his
> > > tag can be available only in overlay or addon device-tree blobs. The
> > > symbol has to be resolved when the device-tree blob is applied on top=
 of
> > > a base device-tree.
> > >=20
> > > It is followed by three values and a possible alignment padding:
> > >   - name (string including \0)
> > >       The export symbol name. I.e. the name used to reference this
> > >       exported symbol.
> > >   - padding:
> > >       Padding (0x00) added to have the next value aligned on 32bit.
> > >   - phandle (32bit)
> > >       A placeholder for a phandle value.
> > >       This placeholder can be used during some dtb manipulation to st=
ore
> > >       a temporary phandle value. =20
> >=20
> > Yuck.
>=20
> Will see what I can do to avoid this placeholder.
>=20
> I need to store the phandle value related to this symbol during the symbol
> resolution. This is done by addon_resolve_phandles() available in
> libfdt/fdt_addon.c in patch 70.
>=20
> libfdt is not designed to perform allocation to store temporary values. It
> manipulates data directly mapped from dtb working with offset in dtb blob
> without any other kind of object. No specific objects (C struct) for node,
> properties, markers, ...

I know. I designed it that way.

Tangent: I have thought that it might be useful to have a diffferent
dt library designed for non-flat trees - i.e. using allocations and
pointers to allow O(1) edits (as well as import/export to flat tree,
of course).  I think that would better suit some of the more complex
tree manipulation many things are doing these days.  I've never had
remotely enough time to look into it, but fwiw, I think the idea's
good.

> To have an area for this phandle value, a room reserved in dtb was really
> the easier way.
>=20
> But well, I understand your "yuck".

Yeah, I do realise that lack of free space to put things can make
things really tricky.  I hope we can find a way around this.

> I think it will be quite tricky to store this temporary phandle value
> without allocating some additional data.
>=20
> This placeholder simplified a lot of things but well, I think I need to f=
ind
> an other solution.
>=20
> If anyone has any ideas to store the temporary phandle value, I am all ea=
rs.
>=20
> Best regards,
> Herv=E9
>=20
>=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

--w/oBFm/TrS5PBwNI
Content-Type: application/pgp-signature; name=signature.asc

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

iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAml6ubIACgkQzQJF27ox
2Gf6txAApTuNovQCuo3a0InAgh9NA4ISvAJHfHNhG2S4L/gSGVKno3pzYs6+teT+
HUZCpaFVxkyr/TNXWkK9MeXvflQaAvHZrM4W1/H76TAjz34D2Fyi4MMkdV1V9LF0
JygynDvJH55Prklwv4wzBYUisbY9Ebj2c5OpC+9QwtZ50BeOhjFOYHWGjMLqBU7X
s/HQdkTEBTTwzFnM8okJVkAlIFl9/bLtZ3DrlQTlazkWf3y5jgGstyhSWG12O50l
YwT4iXpCrEjup2VmXVPINxmcJtyOz1vGb8+Dz9Ob5P5u6azmCktRGbndkSHXttHO
5foLkTBIthcoFHQi4Ii1FXDfq/1pgf9R2MMDL8u7CMnAP1XzWW7e5HAG+izr1mH2
T1m3KYkudlUOqOzmb34BTvnF6jDuU3LBXoNIR3TQEUOv4kmPLZkYPHdbGXOEnbqc
WmFyqiZIMRkXPwHKfZ1ioNkKZHUtXvDdXffLxkKFtgngYbBOxkqCd7KfGsxQNowS
QTaqnBtZZzvTimuOF/2dC3dTswVB5Ry8Hb/uBioYrSITIzXlWg5jRsk7Dlu6+X29
tdeSa24F99WyGyiAT9sOy7G2og7uFfhkcZAcyN3euN6toFhJtjILCrSd7p4izwoU
+0g3uFqeEppkxPAm6uYl7mNGvPYr5gNuzPFRX6WCoKtdyfvnrkw=
=3B3y
-----END PGP SIGNATURE-----

--w/oBFm/TrS5PBwNI--