linux-kernel - Re: [RFC PATCH 29/77] Add support for FDT_EXPORT_SYM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXq5s-XdN79YzOHF@zatzit>
Date: Thu, 29 Jan 2026 12:36:51 +1100
From: David Gibson <david@...son.dropbear.id.au>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ayush Singh <ayush@...gleboard.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	devicetree-compiler@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree-spec@...r.kernel.org,
	Hui Pu <hui.pu@...ealthcare.com>,
	Ian Ray <ian.ray@...ealthcare.com>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [RFC PATCH 29/77] Add support for FDT_EXPORT_SYM_REF dtb tag

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@...son.dropbear.id.au> 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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)