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

Geert Uytterhoeven
2025-09-09T13:05:03Z

Hi Hervé,

On Tue, 9 Sept 2025 at 11:41, Herve Codina <herve.codina@bootlin.com> wrote:
> 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.

Probably we also want header files under <dt/bindings/...> that define
the (sole) symbols that are provided by a connector, and can be consumed
by an attached board? Cfr. C header files defining an API.
In case of multiple connectors (esp. of the same type), we need to
specify a prefix before including the header file (see also namespacing
below).

>
> >
> > > };
> > >
> > > ---- 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
>
> This allows to apply an overlay to a specific node without any modification
> of the overlay dtb (dtbo).

Which currently supports a single node/connector.

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

I think the above describes it well, thanks!

However, I am not so fond of having to describe yet another connector
that contains connA and connB. E.g. a base board with 6 PMOD connectors
would need to describe 30 combinations...

> > > A reference to connector (&connector) from the addon will be resolve
> > > to a reference to &conn0 (phandle of the connector0 node.
> >
> > To handle the addon with multiple connectors we might want an
> > (optional) remapping / renaming on the addon side as well. Or maybe
> > simpler, we could allow namespacing the references on the addon side.
>
> I think you talk about the Geert use case.
> Geert, an example should be welcome.
>
> The plan was to apply the DT related to an addon at a connector node.
> Maybe this will not fit well with Geert's use case but to know if it
> fits or not and to find the best way to handle this use case, an
> example is needed.

A PMOD Type 2A (expanded SPI) connector provides SPI and 4 GPIOS.
A PMOD Type 6A (expanded I2C) connector provides I2C and 4 GPIOS.
Hence a plug-in board that needs SPI, I2C, and a few GPIOs, would need
to plug into two PMOD connectors.

Or:
A PMOD Type 1A (expanded GPIO) connector provides 8 GPIOS.
Hence a non-multiplexed dual 7-segment LED display plug-in board needs
14 or 16 GPIOS, and thus would plug into two PMOD connectors.

To plug into two connectors, a mapping needs to provided between two
connectors on base and add-on board.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds