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