Message-ID: <20250918100619.08501259@bootlin.com>
Date: Thu, 18 Sep 2025 10:06:19 +0200
From: Herve Codina <herve.codina@...tlin.com>
To: David Gibson <david@...son.dropbear.id.au>, Krzysztof Kozlowski
 <krzk@...nel.org>, Rob Herring <robh@...nel.org>, Andrew Davis
 <afd@...com>, Wolfram Sang <wsa+renesas@...g-engineering.com>
Cc: Ayush Singh <ayush@...gleboard.org>, 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

On Thu, 18 Sep 2025 09:44:09 +0200
Herve Codina <herve.codina@...tlin.com> wrote:

> Hi David,
> 
> On Thu, 18 Sep 2025 13:16:32 +1000
> David Gibson <david@...son.dropbear.id.au> wrote:
> 
> ...
> 
> > > > Thoughts above suggest a different direction, but here's what I was
> > > > thinking before:
> > > > 
> > > > base board:
> > > > 
> > > > 	connector {
> > > > 		/export/ "i2c" &i2c0;
> > > > 	};
> > > > 
> > > > addon:
> > > > 	eeprom@10 {
> > > > 		compatible = "foo,eeprom";
> > > > 		bus-reg = <&i2c 0x10>;
> > > > 	}
> > > > 
> > > > Or, if the addon had multiple i2c devices, maybe something like:
> > > > 
> > > > 	board-i2c {
> > > > 		compatible = "i2c-simple-bridge";
> > > > 		bus-ranges = <&i2c 0 0x3ff>; /* Whole addr space */
> > > > 		eeprom@10 {
> > > > 			compatible = "foo,eeprom";
> > > > 			reg = <0x10>;
> > > > 		}
> > > > 		widget@20 {
> > > > 			compatible = "vendor,widget";
> > > > 			reg = <0x20>;
> > > > 		}
> > > > 	}
> > > > 
> > > > Writing that, I realise I2C introduces some complications for this.
> > > > Because it has #size-cells = <0>, ranges doesn't really work (without
> > > > listing every single address to be translated).  Likewise, because we
> > > > always need the parent bus phandle, we can't use the trick of an empty
> > > > 'ranges' to mean an identity mapping.
> > > > 
> > > > We could invent encodings to address those, but given the addon with
> > > > multiple connectors case provides another incentive for a single
> > > > connector to allow adding nodes in multiple (but strictly enumerated)
> > > > places in the base device tree provides a better approach.    
> > > 
> > > and the "place in base device tree" is the goal of the extension bus.
> > > 
> > > The strict enumeration of nodes enumerated is done by two means:
> > >  - extension busses at connector level
> > >    Those extensions are described as connector sub-nodes.
> > >    The addon DT can only add nodes in those sub-nodes to describe devices
> > >    connected to the relared extension bus.
> > >  - export symbols
> > >    An addon DT can only use symbols exported to reference symbols outside
> > >    the addon DT itself.
> > > 
> > > Can I assume that bus extensions we proposed (i2c-bus-extension and
> > > spi-bus-extension) could be a correct solution ?    
> > 
> > Maybe?  I prefer the idea of a universal mechanism, not one that's
> > defined per-bus-type.
> > 
> > 
> > Also, IIUC the way bus extension operates is a bit different - nodes
> > would be "physically" added under the bus extension node, but treated
> > logically as if they go under the main bus.  What I'm proposing here
> > is something at the actualy overlay application layer that allows
> > nodes to be added to different parts of the base device tree - so you
> > could add your i2c device under the main i2c bus.  
> 
> I think we should avoid this kind of node dispatching here and there in
> the base DT.
> 
> We work on decoupling busses wired to a connector and dispatching nodes
> looks like this decoupling is ignored.
> 
> IMHO, keeping devices available on an addon board as nodes under the
> connector is a real hardware representation.
> 
> Also, at runtime, once an addon board DT is applied, when you look at
> your current DT either using /proc/device-tree or some links such as
> /sys/bus/devices/.../of_node, the connector and extension bus appear
> and clearly identify devices behind the connector.
> 
> > 
> > That approach does complicate removal, but its not as bad as overlays
> > at the moment, because a) it could be limited to adding new nodes, not
> > modifying existing ones and b) the connector would specify exactly the
> > places that additions are allowed.
> >   
> 
> I think bus extensions comply with a) and b).
> 
> Yes, bus extensions need to be handled per-bus types but they have the
> advantage of keeping the hardware reality well described and visible at
> runtime in term of "wiring" topology.
> 
> Whatever the solution, this will already be handled per-bus types.
> Only busses that support runtime DT node addition/removal (OF_RECONFIG_*
> notifications in the kernel implementation) will support adding or
> removing nodes.
> 
> Your approach is more complex, dispatch node here and there and actually
> is also a per-bus types solution.
> 
> I think, in order to choose between both solutions, the main question is:
> Do we want to dispatch nodes provided by an addon DT everywhere in the base
> DT ?
> 
> IMHO, the answer is no.
> 
> Rob, others, any opinion ?
> 

The base DT describes the base board hardware.

With this in mind, adding a node at some location other than behind a
connector node means that you add a new device on this board and not on
something behind a connector. In other words this describes a physical
modification of the base board itself.

Best regards,
Hervé

Powered by blists - more mailing lists