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

Message-ID: <20250911122333.2e25e208@bootlin.com>
Date: Thu, 11 Sep 2025 12:23:33 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: David Gibson <david@...son.dropbear.id.au>, Ayush Singh
 <ayush@...gleboard.org>, 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

Hi Geert,

On Thu, 11 Sep 2025 10:54:02 +0200
Geert Uytterhoeven <geert@...ux-m68k.org> wrote:

> Hi Hervé,
> 
> On Thu, 11 Sept 2025 at 10:48, Herve Codina <herve.codina@...tlin.com> wrote:
> > On Wed, 10 Sep 2025 14:33:45 +1000
> > David Gibson <david@...son.dropbear.id.au> wrote:  
> > > On Tue, Sep 09, 2025 at 11:41:26AM +0200, Herve Codina wrote:  
> > > > Suppose a base board with 2 connectors:
> > > >  - connA
> > > >  - connB
> > > >
> > > > Case 1: Addons are independant
> > > >                +--------+
> > > >   connA <----> | AddonA |
> > > >                +--------+
> > > >                           +--------+
> > > >   connB <---------------->| AddonB |
> > > >                           +--------+
> > > >
> > > > With addonA and B two addon board each connected at one connector without any
> > > > relationship between addon A and B
> > > >
> > > > Case 2: Only one Addons using ressources from both connector
> > > >
> > > >                 +------+
> > > >   connA <-----> |Addon |
> > > >                 |      |
> > > >   connB <-----> |      |
> > > >                 +------+  
> > >
> > > Case 2 is what I'm talking about.  Case 1 is the easy one.
> > >  
> > > > The addon is connected to both connector and uses ressources from connA and
> > > > connB in a dependent manner.
> > > >
> > > >
> > > > The Case 2 can be solved using a connector that described both connA and connB.
> > > > Having the split connA and connB is a mechanical point of view.  
> > >
> > > I don't think that's a good solution, because it means you have to
> > > make that decision at the board layer.  If I understand his case
> > > correctly, you have a board where you could do either case 1 or case 2
> > > at runtime.  We'd want the differences between these cases to only be
> > > reflected on the addon device tree, not the base board device tree.  
> >
> > Based on my understanding of Geer's use-case, I think decision at base
> > board level will be needed.
> >
> > base board        addon board
> >   connA +--------+conn1
> >   connB +--------+conn2
> >   connC +
> >
> > Or
> >
> > base board        addon board
> >   connA +--------+conn1
> >   connB +    ,---+conn2
> >   connC +---'
> >
> > Or any other combination that would match.
> >
> > From the addon board point of view, the only think we can
> > say is "me, as an addon board, I need a connector of type 'foo' and a
> > connector of type 'bar'".
> >
> > Also, at base board level, statically defined in the DT
> > connA is described (type 'foo'), connB and connC are
> > described (type 'bar').  
> 
> Correct.
> 
> > 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).

Best regards,
Hervé