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 [off-list ref] wrote:

quoted

On Tue, 9 Sep 2025 15:09:18 +1000
David Gibson [off-list ref] wrote:

quoted

quoted

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.

quoted

Now, questions are:
  - 1) How to describe a connector?
  - 2) How to reference resources provided at connector level from an add-on?

Right.

quoted

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

quoted

quoted

quoted

  };

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

quoted

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

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