Re: Device tree representation of (hotplug) connectors: discussion at ELCE
From: Ayush Singh
Date: Tue Sep 16 2025 - 08:24:02 EST
On 9/16/25 15:44, Geert Uytterhoeven wrote:
Hi Hervé,
On Tue, 16 Sept 2025 at 08:46, Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
On Mon, 15 Sep 2025 14:51:41 +1000
David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, Sep 11, 2025 at 10:48:28AM +0200, Herve Codina wrote:
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.
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.
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.
Gr{oetje,eeting}s,
Geert
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?
Also, I would assume that most such connectors would want to provide
some kind of configfs based API to add/remove addon boards.
Best Regards,
Ayush Singh