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: <CAMuHMdUUGoaetdsTEVx27TYQZ_khzyCn0wzi2+TibYcvkg1fXw@mail.gmail.com>
Date: Thu, 11 Sep 2025 10:54:02 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Herve Codina <herve.codina@...tlin.com>
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 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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds