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

[Herve Codina <herve.codina@bootlin.com>]

Hi Ayush,

On Thu, 11 Sep 2025 17:45:17 +0530
Ayush Singh <ayush@beagleboard.org> wrote:

> On 9/11/25 15:53, Herve Codina wrote:
> > Hi Geert,
> >
> > On Thu, 11 Sep 2025 10:54:02 +0200
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >  
> >> 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.
> >>  
> > 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).
> >
> > Best regards,
> > Hervé
> >  
> 
> 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.

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.

Best regards,
Hervé