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: <CAMuHMdULiX83n5bLEipE1j99HyuyXCpAYS9qYu-8y_vmEyO_ag@mail.gmail.com>
Date: Thu, 11 Sep 2025 15:08:33 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Herve Codina <herve.codina@...tlin.com>
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

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.

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