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

Hi Hervé,

On Thu, 11 Sept 2025 at 14:45, Herve Codina <[email protected]> wrote:
> On Thu, 11 Sep 2025 17:45:17 +0530
> Ayush Singh <[email protected]> wrote:
> > On 9/11/25 15:53, Herve Codina wrote:
> > > On Thu, 11 Sep 2025 10:54:02 +0200
> > > Geert Uytterhoeven <[email protected]> wrote:
> > >> On Thu, 11 Sept 2025 at 10:48, Herve Codina <[email protected]> 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 -- [email protected]

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