On 9/16/25 19:04, Geert Uytterhoeven wrote:

Hi Ayush,

On Tue, 16 Sept 2025 at 14:22, Ayush Singh [off-list ref] wrote:

quoted

On 9/16/25 15:44, Geert Uytterhoeven wrote:

quoted

On Tue, 16 Sept 2025 at 08:46, Herve Codina [off-list ref] wrote:

quoted

On Mon, 15 Sep 2025 14:51:41 +1000
David Gibson [off-list ref] wrote:

quoted

On Thu, Sep 11, 2025 at 10:48:28AM +0200, Herve Codina wrote:

quoted

  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'".

Agreed.

quoted

Also, at base board level, statically defined in the DT
connA is described (type 'foo'), connB and connC are
described (type 'bar').

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.

Agreed.

quoted

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.

Yes.  Although if the addons have an EEPROM, or some other sort of ID
register, it may be possible for some connector drivers to probe this.

Right, I think we agree that a driver is needed to help in the mapping at
least when multiple connectors are involved.

I agree you need a driver to read an ID EEPROM.
But why would you need a driver if no ID EEPROM is involved?
If the connector types on base board and add-on match, it should work.

How would a connector be disabled in such a setup? I guess maybe status
property can be used while applying overlay to check if the connector is
enabled. But maybe that goes outside the scope of fdtoverlay?

Why would you want to disable a connector?

So a lot of embedded SoCs (eg. TI AM6254 [0]) have co-processors (M4F in 
case of AM6254). These co-processors can run full blow RTOS (most 
BeagleBoard boards like PocketBeagle 2 [1] have Zephyr support). When 
using a peripheral from the co-processor running such RTOS, it needs to 
be disabled on Linux side.

quoted

Also, I would assume that most such connectors would want to provide
some kind of configfs based API to add/remove addon boards.

Yes, we need some way to configure add-on board add/remove,
and on which connector(s).

Gr{oetje,eeting}s,

                         Geert

Best Regards

Ayush Singh


[0]: https://www.ti.com/product/AM625

[1]: https://www.ti.com/product/AM625