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

Hi Hervé,

On Tue, 9 Sept 2025 at 11:41, Herve Codina <[email protected]> wrote:
> On Tue, 9 Sep 2025 15:09:18 +1000
> David Gibson <[email protected]> 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 -- [email protected]

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