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

David Gibson
2025-09-10T04:36:51Z

[-- Attachment #1: Type: text/plain, Size: 8584 bytes --]

On Tue, Sep 09, 2025 at 03:04:49PM +0200, Geert Uytterhoeven wrote:
> 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

Yes. Connector types should have their own bindings, describing which
symbols are available to things that plug into it.

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

And it would mean that the OS can't easily reason about which
connector slots are currently occupied.

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

--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]