Message-ID: <aMEAXrAC0uEW2sCc@zatzit>
Date: Wed, 10 Sep 2025 14:36:46 +1000
From: David Gibson <david@...son.dropbear.id.au>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Herve Codina <herve.codina@...tlin.com>,
	Ayush Singh <ayush@...gleboard.org>,
	Luca Ceresoli <luca.ceresoli@...tlin.com>,
	Krzysztof Kozlowski <krzk@...nel.org>, devicetree@...r.kernel.org,
	Rob Herring <robh@...nel.org>, Jason Kridner <jkridner@...il.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	devicetree-compiler@...r.kernel.org, linux-kernel@...r.kernel.org,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	Andrew Davis <afd@...com>
Subject: Re: Device tree representation of (hotplug) connectors: discussion
 at ELCE

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@...tlin.com> wrote:
> > On Tue, 9 Sep 2025 15:09:18 +1000
> > David Gibson <david@...son.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@...ux-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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists