linux-kernel - Re: [RFC PATCH 35/77] Add support for FDT_IMPORT

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20260119153629.26fa0f94@bootlin.com>
Date: Mon, 19 Jan 2026 15:36:29 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
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

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.

Best regards,
Hervé