linux-kernel - Re: Device tree representation of (hotplug) connectors: discussion at ELCE

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] [day] [month] [year] [list]

Message-ID: <20250911155842.796c47fa@bootlin.com>
Date: Thu, 11 Sep 2025 15:58:42 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Ayush Singh <ayush@...gleboard.org>, David Gibson
 <david@...son.dropbear.id.au>, Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Krzysztof Kozlowski <krzk@...nel.org>, devicetree@...r.kernel.org, Rob
 Herring <robh@...nel.org>, Jason Kridner <jkridner@...il.com>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 devicetree-compiler@...r.kernel.org, linux-kernel@...r.kernel.org, Thomas
 Petazzoni <thomas.petazzoni@...tlin.com>, Andrew Davis <afd@...com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
 at ELCE

On Thu, 11 Sep 2025 15:08:33 +0200
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> Hi Hervé,
> 
> On Thu, 11 Sept 2025 at 14:45, Herve Codina <herve.codina@...tlin.com> wrote:
> > On Thu, 11 Sep 2025 17:45:17 +0530
> > Ayush Singh <ayush@...gleboard.org> wrote:  
> > > On 9/11/25 15:53, Herve Codina wrote:  
> > > > On Thu, 11 Sep 2025 10:54:02 +0200
> > > > Geert Uytterhoeven <geert@...ux-m68k.org> wrote:  
> > > >> On Thu, 11 Sept 2025 at 10:48, Herve Codina <herve.codina@...tlin.com> wrote:  
> > > >>> The choice to map connA to the type 'foo' connector expected by the addon
> > > >>> and the choice to map connB or connC to the type 'bar' connector expected by
> > > >>> the addon can only be done at runtime and probably with the help of a driver
> > > >>> that have the knowledge of the 3 connectors.
> > > >>>
> > > >>> I have the feeling that the choice of physical connectors to which the addon
> > > >>> board is connected to is a human choice when the board is connected.  
> > > >> All these choices and decisions apply to single-connector add-on boards, too.
> > > >>  
> > > > Yes, in our use case (me and Luca), each addon has an eeprom, wired exactly the
> > > > same on all supported addon, which allows to known the exact addon. Also addon
> > > > insertions and removals are detected using some gpios wired to the connector.
> > > >
> > > > Based on that our specific driver handling our specific connector perform the
> > > > following operations on addon insertion detection:
> > > >    - load a first addon DT to have access to the eeprom
> > > >    - Read the eeprom to determine the addon type
> > > >    - load the DT matching with the addon type
> > > >
> > > > This part is of course connector type specific. I mean having an eeprom with
> > > > some encoded addon type values and hotplug detection with gpio is a part of
> > > > the contract between the board and the addon (part of connector specification).  
> > >
> > > My usecase is a bit more complicated, since I am trying to model all the
> > > available headers on BeagleBoard.org sbcs (particularly PocketBeagle 2
> > > initially) as connectors. However, that still ends up being a single
> > > connector which can have multiple addon-boards simultaneously instead of
> > > the other way around.  
> >
> > In that case, a connector cannot have the state "free" or "used" handled
> > globally by a core part.
> >
> > IMHO, each connector drivers should handle this kind of state if relevant.
> > I mean, in case of "pmods" compatible driver having this state per PMOD
> > connector could make sense whereas in "beagle-connector" it doesn't.  
> 
> It depends on whether the add-on board has stacking headers, or not ;-)
> 
> > Also, on my side, with my 2-step DT loading, the first loading should not
> > consider the connector as 'used'.
> >
> > All of that is implied by the "contract" between the board and the addon.
> > It is connector specific and so should be handled by the specific connector
> > driver itself.  
> 
> Since stacking boards is a fairly common use case (beagle, rpi), perhaps
> it makes sense to have a simple method to re-export / forward a connector?
> The alternative would be to re-describe and re-export everything.

You re-apply an addon DT on the same connector. You should see the exact same
symbols without re-exporting anything.

I think that you have to re-export stuff only if, on the addon board itself,
you wire some pins from one connector to an other one.

       +-----------------------------+
       |        Addon board          |
   +---------+                   +--------+
   + conn A  +-------------------+ conn B +
   +         +--,   +--------+   +--------+
   +---------+   '--+ device |       |        
       |            +--------+       |
       +-----------------------------+

Here the resource available at conn A directly wired to conn B should be
re-exported in order to allow another addon connected to conn B to use this
signal.

Multiple addons with conn A connector stacked should see all symbols exported
from the based board related to conn A.

Best regards,
Hervé