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

Hi Hervé,

On Thu, 11 Sept 2025 at 10:48, Herve Codina <[email protected]> wrote:
> On Wed, 10 Sep 2025 14:33:45 +1000
> David Gibson <[email protected]> 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 -- [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