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

[David Gibson]

On Mon, Jan 19, 2026 at 04:46:28PM +0100, Herve Codina wrote:
> Hi David,
> 
> On Thu, 15 Jan 2026 17:25:58 +1100
> David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > 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.
> > > 
> > > 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 not a
> > > local node (i.e. the node is not present in the device-tree blob.). This
> > > 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.
> > > 
> > > 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 store
> > >       a temporary phandle value.  
> > 
> > Yuck.
> 
> Will see what I can do to avoid this placeholder.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> This placeholder simplified a lot of things but well, I think I need to find
> an other solution.
> 
> If anyone has any ideas to store the temporary phandle value, I am all ears.
> 
> Best regards,
> Hervé
> 
> 

-- 
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: signature.asc
Description: PGP signature