On 9/11/25 15:53, Herve Codina wrote:

Hi Geert,

On Thu, 11 Sep 2025 10:54:02 +0200
Geert Uytterhoeven [off-list ref] wrote:

quoted

Hi Hervé,

On Thu, 11 Sept 2025 at 10:48, Herve Codina [off-list ref] wrote:

quoted

On Wed, 10 Sep 2025 14:33:45 +1000
David Gibson [off-list ref] wrote:

quoted

On Tue, Sep 09, 2025 at 11:41:26AM +0200, Herve Codina wrote:

quoted

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.
  

quoted

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.

quoted

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.


Best Regards,

Ayush Singh