linux-kernel - Re: [Discussion] Global vs Local devicetree overlays for addon board + connector setups

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: <20250430165823.076e645b@bootlin.com>
Date: Wed, 30 Apr 2025 16:58:23 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Ayush Singh <ayush@...gleboard.org>, xypron.glpk@....de, Jason Kridner
 <jkridner@...gleboard.org>, Deepak Khatri <lorforlinux@...gleboard.org>,
 Dhruva Gole <d-gole@...com>, Robert Nelson <robertcnelson@...gleboard.org>,
 Andrew Davis <afd@...com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 David Gibson <david@...son.dropbear.id.au>, Luca Ceresoli
 <luca.ceresoli@...tlin.com>, Pantelis Antoniou
 <pantelis.antoniou@...il.com>, "open list:OPEN FIRMWARE AND FLATTENED
 DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, open list
 <linux-kernel@...r.kernel.org>
Subject: Re: [Discussion] Global vs Local devicetree overlays for addon
 board + connector setups

Hi Geert,

On Wed, 30 Apr 2025 16:31:17 +0200
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> Hi Hervé,
> 
> On Wed, 30 Apr 2025 at 16:09, Herve Codina <herve.codina@...tlin.com> wrote:
> > On Wed, 30 Apr 2025 17:37:33 +0530
> > Ayush Singh <ayush@...gleboard.org> wrote:
> >
> > ...
> >  
> > > 1. __symbols__ based approach [3]
> > >
> > >
> > > This was originally proposed by Andre Davis [3]. It defines an overlay
> > > with just special names in `__symbols__`, which is used along with an
> > > overlay for the addon-board, which makes use of the node names defined
> > > in the connector `__symbols__` overlay. Please take a look at the
> > > original patch series since it provides a working example of how it can
> > > be used [3].
> > >  
> >
> > The __symbols__ based approach needs 2 overlays to handle the case where
> > 2 connectors (A and B) are present an you want to connect a board described
> > by a single overlay.
> >
> > The first overlay applied "adapts" the __symbols__ node for the connector
> > where the board is connected (for instance connector A) in order to have
> > the symbols used by the overlay describing the board resolved to the
> > correct symbols.
> >
> > I think this open race conditions when the overlay is applied by the kernel
> > itself. Indeed, we need to perform 2 steps in an atomic way:
> >   1) Adapt symbols
> >   2) Applied board overlay  
> 
> I think that can be solved by not applying them in two steps, but by
> in-memory merging of the symbol and board overlays first, and applying
> the result.

Yes, indeed.

This implies a significant work for the __symbols__ based approach. I think
we can say that "it works pretty well with existing infrastructure" is no
more fully true.

Best regards,
Hervé