linux-kernel - Re: [RFC PATCH 19/77] dtc: Introduce export symbols

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: <20260119145120.724c419d@bootlin.com>
Date: Mon, 19 Jan 2026 14:51:20 +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 19/77] dtc: Introduce export symbols

Hi David,

On Mon, 19 Jan 2026 16:51:21 +1100
David Gibson <david@...son.dropbear.id.au> wrote:

> On Fri, Jan 16, 2026 at 05:27:35PM +0100, Herve Codina wrote:
> > Hi David,
> > 
> > On Thu, 15 Jan 2026 16:52:26 +1100
> > David Gibson <david@...son.dropbear.id.au> wrote:
> >   
> > > On Mon, Jan 12, 2026 at 03:19:09PM +0100, Herve Codina wrote:  
> > > > Export symbols allow to define a list of symbols exported at a given
> > > > node level. Those exported symbols can be used by an addon when the
> > > > addon is applied on the node exporting the symbols.    
> > > 
> > > This seems to imply an addon always applies at a single node location.
> > > I'm not sure that's a good design choice, since I don't see how it
> > > covers the case of something that connects to several connectors.  
> > 
> > Apply the addon on a node that knows about those connectors.  
> 
> That seems limiting to me, because it requires the base tree to know
> about all possible connector combinations, which I'm not sure is
> feasible.  If I understood Geert(?)'s case properly, there are use
> cases where a board might have, say, six "type foo" connectors, and an
> addon board could connect to any two of those.  Of a board might have
> 3 "type foo" and 3 "type bar" connectors and an addon board needs to
> connect to (any) of each.  It seems much more natural to me that at
> attach time you say
> 	"addon foo 0 => board foo 1, addon foo 1 => board foo 5"
> or	"addon foo 0 => board foo 2, addon bar 0 => board bar 1"

Who can perform this mapping ?

The user applying the addon if a tool is used such as fdtaddon for instance
(even if this kind of mapping is not yet available in fdtaddon I proposed).

Or a driver that knows about the board connectors.

This driver will apply the addon dtb and provide custom mapping between
symbols expected by the addon (/import/) and symbols provided by the board.

> 
> Rather than the board itself having to anticipate all combinations.
> 
> > > > In order to perform
> > > > its symbol resolution. Any unresolved phandle value will be resolved
> > > > using those exported symbols.
> > > > 
> > > > The feature is similar to __symbols__ involved with overlay but while
> > > > all symbols are visible with __symbols__, only specific symbols
> > > > (exported symbols) are visible with export symbols.    
> > > 
> > > This paragraph doesn't make sense to me.  What's a "symbol" if it's
> > > not something in __symbols__ or export symbols?  
> > 
> > An imported symbols ?
> > 
> > /import/ foo "blabla";
> > 
> > from the addon point of view where this /import/ is present, 'foo' is a
> > symbol.  
> 
> I guess, but existing plugin stuff doesn't really have imported
> symbols, so the example doesn't really illuminate the difference from
> the status quo.

A plugin need to know about all possible symbols available on the board
is applied too. This is the purpose of __symbols__. This just means that for
plugin all possible symbols are imported and symbol translation is not possible.

A plugin is designed for a specific base board. It needs to know about each
busses and how they are wired.

I mean a plugin references i2c5, the i2c controller number 5, and i2c5 needs
to be present in __symbols__.

The target property in __overlay__ identify the target node. Here also, this
is dependent on the board the plugin is applied to.

Addons depend only on the node, describing the connector, they are applied
to. They do not depend on the full specific board where this connector is
available.

Two different boards can have the same connector available and a given board
can have two connectors of the same family the addon can be connected to.

Best regards,
Hervé