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

Herve Codina
2025-09-16T06:46:46Z

Hi David,

+CC Wolfram

On Mon, 15 Sep 2025 14:51:41 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Sep 11, 2025 at 10:48:28AM +0200, Herve Codina wrote:
> > Hi David,
> >
> > On Wed, 10 Sep 2025 14:33:45 +1000
> > David Gibson <david@gibson.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@gibson.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 +---'
>
> I'm not sure what you mean by a decision at the base board level. I
> certainly don't think this should be in the base DT. I'd see this as
> a runtime parameter needed when you apply/insert/activate the addon.
> That's not really any different from addons with a single connector.
> To allow for base boards with multiple instances of that connector
> you'd need to specify at insert time which instance you're attaching
> to.
>
> That information could be supplied by the user, or in the case of
> connectors that can be probed in some way (e.g. an EEPROM) the
> connector driver could supply the information.
>
>
> Which does make me think, considering this case says to me that
> conceptualizing the choice of where to plug an addon as "subnode in
> the base tree it goes under" is not a good idea. That's not really
> going to work for a multiple connector addon.
>
> So, we can specify where an addon goes by which "connector" it
> attaches to. That connector would have an explicit entry in the base
> tree, but it could reference multiple places to add nodes within that
> base tree. Which means thinking about it that way, we might not need
> 'bus-reg' / 'bus-ranges' after all, and in some cases maybe not bus
> extensions either.
>
> Adding nodes in multiple places makes removal a bunch more complicated
> (although it's still much better than overlays being able to modify
> *anywhere*).
>
> > 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'".
>
> Agreed.
>
> > 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.
>
> Agreed.
>
> > 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.
>
> Yes. Although if the addons have an EEPROM, or some other sort of ID
> register, it may be possible for some connector drivers to probe this.

Right, I think we agree that a driver is needed to help in the mapping at
least when multiple connectors are involved.

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

Best regards,
Hervé