Message-ID: <aXlzsYleV1AG4ISO@zatzit>
Date: Wed, 28 Jan 2026 13:25:53 +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 35/77] Add support for FDT_IMPORT_SYM dtb tag

On Mon, Jan 19, 2026 at 03:36:29PM +0100, Herve Codina wrote:
> Hi David,
> 
> On Thu, 15 Jan 2026 17:41:11 +1100
> David Gibson <david@...son.dropbear.id.au> wrote:
> 
> > On Mon, Jan 12, 2026 at 03:19:25PM +0100, Herve Codina wrote:
> > > The FDT_IMPORT_SYM dtb tag is a meta-data tag defining an imported
> > > symbol. It can be present globally in an addon dtb (i.e. outside nodes
> > > definition) meaning that this symbol needs to be resolved when the dtb
> > > is applied.
> > > 
> > > The tag is followed by two values and possible alignment paddings:
> > >   - name (string including \0)
> > >       The import symbol name. I.e. the name used to reference this
> > >       imported symbol.
> > >   - padding:
> > >       Padding (0x00) added to have the next value aligned on 32bit.
> > >   - compatible (string including \0)
> > >       The compatible string that can be used for symbol resolution.
> > >       This string can be an empty string if it is not relevant.
> > >   - padding:
> > >       Padding (0x00) added to have the next value aligned on 32bit.
> > > 
> > > Example:
> > >   FDT_IMPORT_SYM 'foo1' 0x00 0x00 0x00 'bar,foo'
> > > 
> > >   This means that 'foo1' is an imported symbol and it is 'bar,foo'
> > >   compatible.
> > > 
> > >   This is what is encoded in the dtb when the related dts has the
> > >   following imported symbol defined:
> > >     /import/ foo1: "bar,foo";
> > > 
> > > If several symbols are imported, several FDT_IMPORT_SYM are present.
> > > Each of them defining one imported symbol. For instance, importing
> > > 'foo1' ("bar,foo" compatible) and 'baz1' ("bar,baz" compatible) leads
> > > to the following sequence:
> > >   FDT_IMPORT_SYM 'foo1' 0x00 0x00 0x00 'bar,foo'
> > >   FDT_IMPORT_SYM 'baz1' 0x00 0x00 0x00 'bar,baz'
> > > 
> > > If FDT_IMPORT_SYM tags are present in the dtb, they are present after
> > > the root node definition (i.e. after the FDT_END_NODE related to the
> > > first FDT_BEGIN_NODE).
> > > 
> > > Add support for this new dtb tag.  
> > 
> > Since these are global to the whole tree, would a new block make more
> > sense?
> 
> I don't know.
> 
> Exports symbols are in node blocs and that makes sense. I wouldn't expect
> imports out of the dtb "structure block".
> 
> They could be grouped into an other tag, FDT_INFO_DTB for instance (part of
> the "structure block").
> 
> If you think that a new block is really relevant, I can implement this new
> block.

On further thought, I don't think this is a good idea.  For one thing
adding an extra block makes resizing edits way harder to implement.
For another adding support for multiple upstream connectors might mean
they're no longer quite as global as they are.

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

Powered by blists - more mailing lists