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

Herve Codina
2025-09-18T08:06:34Z

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

> Hi David,
>
> On Thu, 18 Sep 2025 13:16:32 +1000
> David Gibson <david@gibson.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é