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

David Gibson <[email protected]> Mon, 29 Sep 2025 19:23:21 +1000
Newsgroups	org.kernel.vger.devicetree-compiler,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID	<aNpQCboQimgwIkJw@zatzit>
On Wed, Sep 24, 2025 at 02:31:30PM +0200, Herve Codina wrote:
> Hi David,
> 
> On Wed, 24 Sep 2025 13:54:22 +1000
> David Gibson <[email protected]> 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

Ok.  I think there are some further possible distinctions here between:

 a. Rules for connectors in general
 b. Rules for a specific connector type (defined by the connector type
    binding)
 c. Rules for a specific connector instance (defined by the property
    values in that instance).

Possible we can avoid using one or more of those categories, but we
need to consider them and do so conciously.

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

Hmm.  I'm not sure this is a good idea.  I had been envisaging this
new "addon" support as explicitly tied to connectors - you can't
addon, except in a way the base board allows, and connectors are the
way it allows.

> 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 ?

With the distinction from the connector case being that the driver
defines how to interpret the addon at runtime, rather than the base DT
defining it statically?

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

Ok.  So I think the model you're suggesting is this:

 * A bus/port driver (let's call it an "addon driver") can allow addon
   DTs to be plugged in and removed, under constraints defined by that
   driver at runtime.

 * The connector driver would be one specific addon driver, that can
   handle a pretty broad range of not-too-complex addons.  The
   constraints for the addon DT are defined by the properties of the
   connector in the base DT, rather than by runtime logic in the
   driver.

Is that correct?

A few observations

 - This effectively makes an addon driver a special case of a
   discoverable bus/port driver.  Or even DT addons as a library that
   a bus/port driver can use.  Rather than directly updating the Linux
   device model, the driver selects an addon DT and uses that to
   update the Linux device model.

 - The distinction between a connector and a general addon driver, is
   a bit like that between the simple-bus driver and a PCI host bridge
   driver.  The former handles a fairly wide range of relatively
   simple cases, the latter handles a more complex and specialized
   case.

I don't dislike this model, but it does raise some questions (these
are not rhetorical):

1) Is DT a good way of describing the addon?

After all, the addon driver could make updates directly to the Linux
device model from whatever format is convenient.

2) Does it make sense to use the addon to alter the global DT?

Even if the addon is described by a DT, the addon/connector driver
could read that DT and the system DT and make corresponding updates to
the Linux device model without altering the system DT first.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson
signature.asc (application/pgp-signature, 833 B)