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

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

Hi David,

On Wed, 24 Sep 2025 13:54:22 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

...

> > 
> > IMHO, no extra rules are needed in DT addon rules to constraint i2c devices
> > to be added in a connector node, a connector sub-node or an i2c controller
> > node.
> > 
> > This will be constrained by the connector itself (out of DT addon rules).  
> 
> At this point I'm just considering the end-to-end rules we want to
> enforce.  Exactly what stage of the process enforces each rule is
> another question.
> 
> > I mean, according to rule b), the connector will allow some destination
> > places. Either it will allow the i2c controller node or a connector sub-node.  
> 
> Sure.
> 
> > This is specific to the connector definition and it should be out of
> > generic DT addon rules.  
> 
> Hang on... what distinction are you seeing between the "connector
> definition" and "generic DT addon rules".  As I see it we're trying to
> create a protocol that defines both the base rules and what a
> "connector" even means.
> 

The "generic DT addon rules" give rules related to addon from a DT
perspective. In other word "What an addon DT can do"
 - export symbols
 - import symbols
 - Add full node only
 - Don't allow to modify existing node
 - ...

The way addon are used is what I put behind "connector definition".
The connector is a specific node in a DT with a specific comptible string.
The definition of this node will tell "how to use it". For instance:
  - There is 2 gpios available and an addon can use it with <&connector 0> and
    <&connector 1>.
  - There is an i2c bus available and an addon can use if with <&i2c-a>
  - The hotplug mecanism used for this specific connector (gpio, eeprom, ...)
    is also part of the "connector definition".

An external board DT supposed to be connected to this connector should
  - a) Provide its description using an addon DT (compliant with "generic DT
       addon rules")
and

  - b) Use resources from connector the board is connected to (compliant with
       "connector definition").

"generic DT addon rules": DT specification
"connector definition": Connector binding

Today, connectors are going to use the addon feature but I didn't want to
restrict addon feature to connectors.

For instance, a FPGA driver could use the addon feature with an addon DT
to describe the internal part of the FPGA related to the FPGA bitstream
loaded by the FPGA driver. That might make sense, right ?

Also upstream in the kernel, PCI boards can be described using DT.
  https://elixir.bootlin.com/linux/v6.16/source/drivers/misc/lan966x_pci.c
  https://elixir.bootlin.com/linux/v6.16/source/drivers/misc/lan966x_pci.dtso

Using addon DT in that case makes sense too even if a "connector" is not present.

Best regards,
Hervé