Message-ID: <20250911104828.48ef2c0e@bootlin.com>
Date: Thu, 11 Sep 2025 10:48:28 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>
Cc: Ayush Singh <ayush@...gleboard.org>, Luca Ceresoli
 <luca.ceresoli@...tlin.com>, Krzysztof Kozlowski <krzk@...nel.org>,
 devicetree@...r.kernel.org, Rob Herring <robh@...nel.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>, Andrew Davis <afd@...com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
 at ELCE

Hi David,

On Wed, 10 Sep 2025 14:33:45 +1000
David Gibson <david@...son.dropbear.id.au> wrote:

> On Tue, Sep 09, 2025 at 11:41:26AM +0200, Herve Codina wrote:
> > Hi David,
> > 
> > On Tue, 9 Sep 2025 15:09:18 +1000
> > David Gibson <david@...son.dropbear.id.au> wrote:
> > 
> > ...
> >   
> > > > I think that a connector is something with a bunch of resources provided
> > > > by the board where the connector is soldered. Those resources are wired
> > > > to the connector and defined by the connector pinout.
> > > > 
> > > >      3v3   ------- Pin 0
> > > >   i2c_scl  ------- Pin 1
> > > >   i2c_sda  ------- Pin 2
> > > >     gpio A ------- Pin 3
> > > >     gpio B ------- Pin 4
> > > >      gnd   ------- Pin 5
> > > > 
> > > > IMHO, this need to be described and defined in the base board and an addon can
> > > > only reference resources wired and described by the connector node.    
> > > 
> > > Yes, that's exactly what I'm proposing too.
> > >   
> > > > Now, questions are:
> > > >   - 1) How to describe a connector?
> > > >   - 2) How to reference resources provided at connector level from an add-on?    
> > > 
> > > Right.
> > >   
> > > > Our current approach was:
> > > > ---- base board DT ----
> > > >   connector0 {
> > > > 	gpio-map = <0 &gpio0 12>, /* gpio A wired to gpio 12 of gpio0 controller */
> > > >                    <1 &gpio2 10;  /* gpio B wired to gpio 10 of gpio2 controller */
> > > >         i2c-one {
> > > > 		compatible = "i2c-bus-extension";
> > > > 		i2c-parent = <i2c5>; /* i2c-one wired to i2c5 controller */
> > > > 	};
> > > > 
> > > > 	i2c-two {
> > > > 		compatible = "i2c-bus-extension";
> > > > 		i2c-parent = <i2c6>; /* i2c-two wired to i2c6 controller */
> > > > 	};
> > > > 
> > > > 	/*
> > > >          * From the addon we need to reference:
> > > >          *    - The connector itself,
> > > >          *    - Maybe some pinctrl related to signals wired to the connector,
> > > >          *    - In some cases the i2c bus (HDMI, ddc-i2c-bus = <&i2c-two>;)
> > > >          * 
> > > >          * This was solved introducing the controversial export-symbols node.
> > > >          */    
> > > 
> > > I think the type of connector should also be named on both sides (with
> > > 'compatible' or something like it).  
> > 
> > It makes sense.
> >   
> > >   
> > > >   };
> > > > 
> > > > ---- addon board DT ----
> > > >    {
> > > > 	some-node {
> > > > 		compatible = "foo,bar";
> > > > 		reset-gpios = <&connector 0>; /* gpio A used as a reset gpio */
> > > > 		ddc-i2c-bus = <&i2c-two>;
> > > >         }
> > > > 
> > > >         i2c-one {
> > > > 		eeprom@10 {
> > > > 			compatible = "baz,eeprom"
> > > > 			reg = 10; 
> > > > 		};
> > > > 	};
> > > >    };
> > > > 
> > > > The addon board DT can only be applied at a connector node.    
> > > 
> > > Right.  This is not how overlays work now.  By the nature of how
> > > they're built they apply global updates to the base tree.  That means
> > > we need to spec a new way of describing addons that *is* restricted to
> > > a particular connector slot (or slots, as Geert points out).  Since we
> > > have that opportunity, we should _not_ try to make it a minimal
> > > extension to existing overlay format, but define a new and better
> > > encoding, designed to meet the problems you're looking to address.  
> > 
> > On the kernel side, overlays can be applied at a specific node.
> > The node is chosen when the overlay is apply.
> >   https://elixir.bootlin.com/linux/v6.16/source/drivers/of/overlay.c#L970  
> 
> Huh, I wasn't aware that had already been merged.
> 
> > This allows to apply an overlay to a specific node without any modification
> > of the overlay dtb (dtbo).
> > 
> > Ajush proposed an update to support this feature in fdtoverlay
> >   https://lore.kernel.org/all/20250313-fdtoverlay-target-v1-0-dd5924e12bd3@beagleboard.org/  
> 
> Yes, and I've been disinclined to merge it because I think extending
> overlays in this way, without a more wide-ranging redesign, is not a
> great idea.
> 
> > ...  
> > >   
> > > > > > > 3) bus-reg / bus-ranges
> > > > > > > 
> > > > > > > One thing that makes connector plugins a bit awkward is that they
> > > > > > > often need to add things to multiple buses on the host system (MMIO &
> > > > > > > i2c for a simple case).  This means that once resolved the plugin
> > > > > > > isn't neatly a single subtree.  That's one factor making removal    
> > > > 
> > > > It can be a single subtree if decoupling is present at connector node available
> > > > in the base device tree.    
> > > 
> > > Right - allowing that decoupling is exactly what I'm proposing bus-reg
> > > for.  Note that the case of an addon that plugs into multiple
> > > connectors that Geert pointed out complicates this again.  
> > 
> > Geert's use case needs to be clarified.
> > 
> > Suppose a base board with 2 connectors:
> >  - connA
> >  - connB
> > 
> > Case 1: Addons are independant
> >                +--------+
> >   connA <----> | AddonA |
> >                +--------+
> >                           +--------+
> >   connB <---------------->| AddonB |
> >                           +--------+
> > 
> > With addonA and B two addon board each connected at one connector without any
> > relationship between addon A and B
> > 
> > Case 2: Only one Addons using ressources from both connector
> > 
> >                 +------+
> >   connA <-----> |Addon |
> >                 |      |
> >   connB <-----> |      |
> >                 +------+  
> 
> Case 2 is what I'm talking about.  Case 1 is the easy one.
> 
> > The addon is connected to both connector and uses ressources from connA and
> > connB in a dependent manner.
> > 
> > 
> > The Case 2 can be solved using a connector that described both connA and connB.
> > Having the split connA and connB is a mechanical point of view.  
> 
> I don't think that's a good solution, because it means you have to
> make that decision at the board layer.  If I understand his case
> correctly, you have a board where you could do either case 1 or case 2
> at runtime.  We'd want the differences between these cases to only be
> reflected on the addon device tree, not the base board device tree.

Based on my understanding of Geer's use-case, I think decision at base
board level will be needed.

base board        addon board
  connA +--------+conn1
  connB +--------+conn2
  connC +

Or

base board        addon board
  connA +--------+conn1
  connB +    ,---+conn2
  connC +---'

Or any other combination that would match.

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

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.

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.

> 
> > Also adding and Addon on only one part (connA for instance) should not be an issue
> > if the connector describe both parts.
> > 
> > but well, here again I can miss something.
> > Geert, can you provide details?
> > 
> > ...
> >   
> > > > > > 
> > > > > > There is an i2c-bus-extension [1] and spi-bus-extension proposal to do the
> > > > > > same. But, if we can figure out a common way for all buses, that would be
> > > > > > great.    
> > > > 
> > > > Exactly, this is the purpose of bus extensions.    
> > > 
> > > Right, but redefining it for each bus type seems silly.  
> > 
> > Nexus node properties are re-defined for each kind of resources (interrupt,
> > gpio, pwm, ...).  
> 
> Yes, for historical reasons.  In IEE1275 days, interrupts was
> basically the only thing that worked this way.  gpio and pwm were
> added much later using interrupts as a model.  If we were designing
> from scratch having a common way of defining a nexus would make sense
> too.
> 
> > Why not for bus extensions.  
> 
> So that we don't need to keep defining new bindings for it.
> 
> > Also I am pretty sure that some bus extension will need to define some
> > properties specific to the bus related to the extension.  
> 
> Maybe, but then only those buses that specifically need it need the
> extra binding.
> 
> > > > Also, I don't thing that the 'ranges' property should be used for that purpose.
> > > > The 'ranges' property is used to translate addresses from child addresses space
> > > > to parent addresses space.    
> > > 
> > > The rationale for bus-ranges is that the add-on board could re-expose
> > > one of the buses on the connector (say MMIO for simplicity) to several
> > > chips physically included on the addon board.  We don't want those
> > > sub-chips to need different device nodes depending on whether they're
> > > on an addon board or wired directly onto a main board.  bus-ranges
> > > would allow the root of the connector to create a subtree in which
> > > regular MMIO (or whatever) devices can be described, and then routed
> > > via the connector onto the bus on the main board.  
> > 
> > bus extensions supports this feature without bus-regs nor bus-ranges.  
> 
> bus-reg & bus-ranges allow it for any bus without having to create a
> new binding.
> 
> > A bus extension ended by a sub node in the connector node.
> > Applying the addon DT at the connector node allow the addon to had
> > subnode to the extension node.  
> 
> I don't really understand what point you're making here.

Hardware:
 +------------------+    +----------------------+
 |   base board     |    |      addon board     |
 |  +------+        |    |                      |
 |  | i2c0 |    +-----------+    +------------+ |
 |  |      +----+ connector +----+ eeprom @10 | |
 |  |      |    +-----------+    +------------+ |
 |  +------+        |    |                      |
 +------------------+    +----------------------+

base board DT:
    connector {
	i2c-ctrl {
		compatible = "i2c-bus-extension";
		i2c-parent = <&i2c0>;
        };
    };

addon board DT:
    i2c-ctrl {
	eeprom@10 {
            compatible = "foo,eeprom";
            reg = <10>;
        };
    };

Once addon board DT is applied at the base board connector node, the full
DT is:
    connector {
	i2c-ctrl {
	    compatible = "i2c-bus-extension";
	    i2c-parent = <&i2c0>;

            eeprom@10 {
               compatible = "foo,eeprom";
               reg = <10>;
            };
        };
    };

I probably didn't understand the bus-reg and bus-range usage.
In order to clarify my understanding, using the same hardware example above,
can you provide an example of description using bus-reg & bus-ranges?

Best regards,
Hervé

-- 
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists