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

Geert Uytterhoeven
2025-09-11T08:54:16Z

Hi Hervé,

On Thu, 11 Sept 2025 at 10:48, Herve Codina <herve.codina@bootlin.com> wrote:
> On Wed, 10 Sep 2025 14:33:45 +1000
> David Gibson <david@gibson.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@linux-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