Hi Hervé,

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

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.

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