Message-ID: <20250930090924.1bfc8730@bootlin.com>
Date: Tue, 30 Sep 2025 09:09:24 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Ayush Singh <ayush@...gleboard.org>, Krzysztof Kozlowski
 <krzk@...nel.org>, Rob Herring <robh@...nel.org>, Andrew Davis
 <afd@...com>, Wolfram Sang <wsa+renesas@...g-engineering.com>, Luca
 Ceresoli <luca.ceresoli@...tlin.com>, devicetree@...r.kernel.org, Jason
 Kridner <jkridner@...il.com>, Geert Uytterhoeven <geert@...ux-m68k.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, devicetree-compiler@...r.kernel.org,
 linux-kernel@...r.kernel.org, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
 at ELCE

Hi David,

On Mon, 29 Sep 2025 19:23:21 +1000
David Gibson <david@...son.dropbear.id.au> wrote:

> 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 <david@...son.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  
> 
> 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.

I agree with that.

I think we just need to clarify what is the definition of "connector" in
this context.

I have the feeling that a "connector" for you is where an addon is going to
be applied.

In my mind a connector was the piece of hardware where the addon board is
connected.

Most of the time, this piece of hardware will be represented as a node in the
DT and the addon DT will be applied to this node.

I made the distinction in case of PMOD use case (Geert's use case with
multiple connector). In that case we need to find, probably with external help,
connectors connected to the addon board.

I have the feeling that in that case the description will be:
   /* Base board DT */
   pmod-group {
      pmod-connector1 {
        ...
      };
      pmod-connector2 {
        ...
      };
      pmod-connector3 {
        ...
      };
   };

The addon DT will be applied to pmod-group and the pmod-group driver
selects multiple connectors (pmod-connector1 and/or pmod-connector2
and/or pmod-connector3) according to the addon needs and some external
help in order to applied the addon DT.
   https://lore.kernel.org/all/20250911121103.40ccb112@bootlin.com/

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

Yes

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

Both properties of the connector and runtime logic.

In multiple connector cases, some runtime logic will be needed.

Also, in my use case, several steps are required:
1) Apply an addon DT to describe EEPROM available on all addon boards
   we supports.
2) Read the eeprom to identify the board
3) Select the right full addon DT based on the board idendified
4) Apply the full addon DT

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

The DT goal is to describe hardware and we are describing hardware available
on an addon board. DT description seems perfectly legit for this use case.

Let's try as an exercise. Now we have device tree (DT), let's say we want
to describe addons using the new "Another Representation of Generic
Hardware" (ARGH) syntax.

We need to:
 * implement arghc (similar to dtc)
 * write argh-bindings for chips that already have dt-bindings
 * write new argh_*() functions similar to of_*() functions
 * write new toooling like `make argh_binding_check` and
   `make arghs_check`
 * etc

Or we could look for an existing format and decide to use the device
tree format, which is maybe not perfect, but it works well for a lot of
things and has all these and more implemented already.

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

May I missed something but I think we already discussed this and you appeared
to agree with my arguments in favor of letting the addon alter very specific
nodes in the base tree that are explicitly marked as suitable in the connector
description.
  https://lore.kernel.org/all/aMebXe-yJy34kST8@zatzit/

Best regards,
Hervé

Powered by blists - more mailing lists