[PATCH v3 0/1] i2c: Introduce I2C bus extensions

[PATCH v3 0/1] i2c: Introduce I2C bus extensions

[Herve Codina]

Hi,

An I2C bus can be wired to the connector and allows an add-on board to
connect additional I2C devices to this bus.

Those additional I2C devices could be described as sub-nodes of the I2C
bus controller node however for hotplug connectors described via device
tree overlays there is additional level of indirection, which is needed
to decouple the overlay and the base tree.

This decoupling is performed thanks to the I2C bus extension feature
which is introduced and detailed in patch 2 of this series.

The implementation related to I2C bus extension has been already
proposed as an RFC in Linux [0]. The missing part in this RFC was the
binding.

This binding related to I2C controller is not available in the Linux
repository but in dt-schema repository and so, this series update the
I2C controller binding to introduce the feature.

Compare to the previous iteration, example has been fixed. No
other modification has been done except adding a reviewed-by tag.

In the v1 series review, discussion started but conclusions were not
reached. As a reminder, topics started in the v1 series discussion were
the following:
 - i2c-bus-extension@0: usage of a subnode with unit address
 - Presence of phandles in both direction (double linked list)

[0] https://lore.kernel.org/all/20250205173918.600037-1-herve.codina@bootlin.com/

Best regards,
Hervé Codina

Changes v2 -> v3
  v2: https://lore.kernel.org/all/20250430152201.209797-1-herve.codina@bootlin.com/

  Patch 1:
  Fix the example provided in the commit log.
  Add 'Reviewed-by: Luca Ceresoli'

Changes v1 -> v2
  v1: https://lore.kernel.org/all/20250401081041.114333-1-herve.codina@bootlin.com/

  Patch 1 in v1:
  Removed (already applied)

  Patch 1 (2 in v1):
  Add 'Reviewed-by: Ayush Singh <ayush@beagleboard.org>'

Herve Codina (1):
  schemas: i2c: Introduce I2C bus extensions

 dtschema/schemas/i2c/i2c-controller.yaml | 67 ++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

-- 
2.49.0

[PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Herve Codina]

An I2C bus can be wired to the connector and allows an add-on board to
connect additional I2C devices to this bus.

Those additional I2C devices could be described as sub-nodes of the I2C
bus controller node however for hotplug connectors described via device
tree overlays there is additional level of indirection, which is needed
to decouple the overlay and the base tree:

  --- base device tree ---

  i2c1: i2c@abcd0000 {
      compatible = "xyz,foo";
      i2c-bus-extension@0 {
          i2c-bus = <&i2c_ctrl>;
      };
      ...
  };

  i2c5: i2c@cafe0000 {
      compatible = "xyz,bar";
      i2c-bus-extension@0 {
          i2c-bus = <&i2c_sensors>;
      };
      ...
  };

  connector {
      i2c_ctrl: i2c-ctrl {
          i2c-parent = <&i2c1>;
          #address-cells = <1>;
          #size-cells = <0>;
      };

      i2c_sensors: i2c-sensors {
          i2c-parent = <&i2c5>;
          #address-cells = <1>;
          #size-cells = <0>;
      };
  };

  --- device tree overlay ---

  ...
  // This node will overlay on the i2c-ctrl node of the base tree
  i2c-ctrl {
      eeprom@50 { compatible = "atmel,24c64"; ... };
  };
  ...

  --- resulting device tree ---

  i2c1: i2c@abcd0000 {
      compatible = "xyz,foo";
      i2c-bus-extension@0 {
          i2c-bus = <&i2c_ctrl>;
      };
      ...
  };

  i2c5: i2c@cafe0000 {
      compatible = "xyz,bar";
      i2c-bus-extension@0 {
          i2c-bus = <&i2c_sensors>;
      };
      ...
  };

  connector {
      i2c_ctrl: i2c-ctrl {
          i2c-parent = <&i2c1>;
          #address-cells = <1>;
          #size-cells = <0>;

          eeprom@50 { compatible = "atmel,24c64"; ... };
      };

      i2c_sensors: i2c-sensors {
          i2c-parent = <&i2c5>;
          #address-cells = <1>;
          #size-cells = <0>;
      };
  };

Here i2c-ctrl (same goes for i2c-sensors) represent the part of I2C bus
that is on the hot-pluggable add-on. On hot-plugging it will physically
connect to the I2C adapter on the base board. Let's call the 'i2c-ctrl'
node an "extension node".

In order to decouple the overlay from the base tree, the I2C adapter
(i2c@abcd0000) and the extension node (i2c-ctrl) are separate nodes.

The extension node is linked to the I2C bus controller in two ways. The
first one with the i2c-bus-extension available in I2C controller
sub-node and the second one with the i2c-parent property available in
the extension node itself.

The purpose of those two links is to provide the link in both direction
from the I2C controller to the I2C extension and from the I2C extension
to the I2C controller.

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Ayush Singh <ayush@beagleboard.org>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
---
 dtschema/schemas/i2c/i2c-controller.yaml | 67 ++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/dtschema/schemas/i2c/i2c-controller.yaml b/dtschema/schemas/i2c/i2c-controller.yaml
index 8488edd..8ab7fec 100644
--- a/dtschema/schemas/i2c/i2c-controller.yaml
+++ b/dtschema/schemas/i2c/i2c-controller.yaml
@@ -30,6 +30,13 @@ properties:
     minimum: 1
     maximum: 5000000
 
+  i2c-parent:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      In case of an I2C bus extension, reference to the I2C bus controller
+      this extension is connected to. In other word, reference the I2C bus
+      controller on the fixed side that drives the bus extension.
+
   i2c-scl-falling-time-ns:
     description:
       Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C
@@ -159,6 +166,25 @@ allOf:
         - i2c-scl-has-clk-low-timeout
 
 patternProperties:
+  'i2c-bus-extension@[0-9a-f]+$':
+    type: object
+    description:
+      An I2C bus extension connected to an I2C bus. Those extensions allow to
+      decouple I2C busses when they are wired to connectors.
+
+    properties:
+      reg:
+        maxItems: 1
+
+      i2c-bus:
+        $ref: /schemas/types.yaml#/definitions/phandle
+        description:
+          Reference to the extension bus.
+
+    required:
+      - reg
+      - i2c-bus
+
   '@[0-9a-f]+$':
     type: object
 
@@ -221,3 +247,44 @@ dependentRequired:
   i2c-digital-filter-width-ns: [ i2c-digital-filter ]
 
 additionalProperties: true
+
+examples:
+  # I2C bus extension example involving an I2C bus controller and a connector.
+  #
+  #  +--------------+     +-------------+     +-------------+
+  #  | i2c@abcd0000 |     |  Connector  |     | Addon board |
+  #  |    (i2c1)    +-----+ (i2c-addon) +-----+ (device@10) |
+  #  |              |     |             |     |             |
+  #  +--------------+     +-------------+     +-------------+
+  #
+  # The i2c1 I2C bus is wired from a I2C controller to a connector. It is
+  # identified at connector level as i2c-addon bus.
+  # An addon board can be connected to this connector and connects a device
+  # (device@10) to this i2c-addon extension bus.
+  - |
+    i2c1: i2c@abcd0000 {
+        compatible = "xyz,i2c-ctrl";
+        reg = <0xabcd0000 0x100>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        i2c-bus-extension@0 {
+            reg = <0>;
+            i2c-bus = <&i2c_addon>;
+        };
+    };
+
+    connector {
+        i2c_addon: i2c-addon {
+            i2c-parent = <&i2c1>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            device@10 {
+                compatible = "xyz,foo";
+                reg = <0x10>;
+            };
+        };
+    };
+
+...
-- 
2.49.0

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Rob Herring]

On Wed, Jun 18, 2025 at 3:23 AM Herve Codina <herve.codina@bootlin.com> wrote:
>
> An I2C bus can be wired to the connector and allows an add-on board to
> connect additional I2C devices to this bus.
>
> Those additional I2C devices could be described as sub-nodes of the I2C
> bus controller node however for hotplug connectors described via device
> tree overlays there is additional level of indirection, which is needed
> to decouple the overlay and the base tree:
>
>   --- base device tree ---
>
>   i2c1: i2c@abcd0000 {
>       compatible = "xyz,foo";
>       i2c-bus-extension@0 {

This is at I2C bus address 0? No. You are mixing 2 different address
spaces. Don't do that.

You could solve this with just a property in the parent. If there's
more than 1, then it's just multiple phandles. However I don't think
you need this at all. You can just search the DT for 'i2c-parent' and
find phandles that match the i2c controller node. But why does the
controller driver need to know about connectors? Shouldn't the
connector driver drive this and tell the controller there's more
devices?

Rob

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Luca Ceresoli]

Hello Rob, Wolfram,

[this e-mail is co-written with Hervé]

Rob, Wolfram: this e-mail mentions DT description together with
implementation ideas, but both of your opinions are very relevant here.

On Fri, 1 Aug 2025 13:09:54 -0500
Rob Herring <robh@kernel.org> wrote:

> On Wed, Jun 18, 2025 at 3:23 AM Herve Codina <herve.codina@bootlin.com> wrote:
> >
> > An I2C bus can be wired to the connector and allows an add-on board to
> > connect additional I2C devices to this bus.
> >
> > Those additional I2C devices could be described as sub-nodes of the I2C
> > bus controller node however for hotplug connectors described via device
> > tree overlays there is additional level of indirection, which is needed
> > to decouple the overlay and the base tree:
> >
> >   --- base device tree ---
> >
> >   i2c1: i2c@abcd0000 {
> >       compatible = "xyz,foo";
> >       i2c-bus-extension@0 {  
> 
> This is at I2C bus address 0? No. You are mixing 2 different address
> spaces. Don't do that.
> 
> You could solve this with just a property in the parent. If there's
> more than 1, then it's just multiple phandles. However I don't think
> you need this at all. You can just search the DT for 'i2c-parent' and
> find phandles that match the i2c controller node. But why does the
> controller driver need to know about connectors? Shouldn't the
> connector driver drive this and tell the controller there's more
> devices?

These were the concerns you had raised last April [0], so let's continue
from there and Hervé's follow-up.

Hervé's position was that a double-reference is more effective as every
interested party (the i2c adapter and the i2c extension node) have an
explicit description of the connected party/parties. Besides, this looks
consistent with the bidirectional links in remote-endpoints, which has
similarities.

OTOH I agree a single-direction link (i2c extension node to i2c
adapter) should work, in principle. However there are issues, mainly in
how an adapter finds out about the extensions when it is probed after
them.

Your proposal of searching the whole tree involves a lot of searches in
a potentially large tree, even though I don't expect it to happen often
at least for the use cases I'm aware of.

But, more important, Hervé pointed out an "i2c-parent" property is
already used for different purposes (i2c muxes). We could choose
another string but that would be fragile too.


One idea is to unambiguously mark i2c bus extension nodes with a
compatible string:

  connector {
      i2c_ctrl: i2c-ctrl {
          compatible = "i2c-bus-extension"; // <-----
          i2c-parent = <&i2c1>;
          #address-cells = <1>;
          #size-cells = <0>;
      };
  };

And then implementing a device driver for the i2c bus extension.

This would allow to ensure extensions are probed after their adapter
(thanks to probe deferral) and at that point can register themselves at
the adapter. In other words the device driver core would provide the
synchronization between adapter, bus extension, and devices on the bus
extension.


A different option is to only have the "i2c-parent" phandle in the
extension node and nothing else in DT (no bidirectional link, no
compatible string), without any full-tree searches.

On the implementation side, the connector driver when probing would
register the extension nodes at the I2C core, which would maintain a
list of extension nodes. This is important when the connector probes
first. Then when any adapter probes the core would iterate over the
list to check whether the newly-probed adapter is pointed to by one of
the registered bus extensions, and then start populating the devices on
the matching bus extension(s).

A lot of care would have to be put in the disconnection path and while
removing any bus extension from the global list, which could race with
the I2C core using the list itself. The drive core wouldn't do it for
us for free.


Rob, Wolfram, what are your opinions about these options, and which is
worth pursuing? Do you have better proposals?

[0] https://lore.kernel.org/all/20250402102123.30391c27@bootlin.com/

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Rob Herring]

On Fri, Aug 8, 2025 at 11:08 AM Luca Ceresoli <luca.ceresoli@bootlin.com> wrote:
>
> Hello Rob, Wolfram,
>
> [this e-mail is co-written with Hervé]
>
> Rob, Wolfram: this e-mail mentions DT description together with
> implementation ideas, but both of your opinions are very relevant here.
>
> On Fri, 1 Aug 2025 13:09:54 -0500
> Rob Herring <robh@kernel.org> wrote:
>
> > On Wed, Jun 18, 2025 at 3:23 AM Herve Codina <herve.codina@bootlin.com> wrote:
> > >
> > > An I2C bus can be wired to the connector and allows an add-on board to
> > > connect additional I2C devices to this bus.
> > >
> > > Those additional I2C devices could be described as sub-nodes of the I2C
> > > bus controller node however for hotplug connectors described via device
> > > tree overlays there is additional level of indirection, which is needed
> > > to decouple the overlay and the base tree:
> > >
> > >   --- base device tree ---
> > >
> > >   i2c1: i2c@abcd0000 {
> > >       compatible = "xyz,foo";
> > >       i2c-bus-extension@0 {
> >
> > This is at I2C bus address 0? No. You are mixing 2 different address
> > spaces. Don't do that.
> >
> > You could solve this with just a property in the parent. If there's
> > more than 1, then it's just multiple phandles. However I don't think
> > you need this at all. You can just search the DT for 'i2c-parent' and
> > find phandles that match the i2c controller node. But why does the
> > controller driver need to know about connectors? Shouldn't the
> > connector driver drive this and tell the controller there's more
> > devices?
>
> These were the concerns you had raised last April [0], so let's continue
> from there and Hervé's follow-up.
>
> Hervé's position was that a double-reference is more effective as every
> interested party (the i2c adapter and the i2c extension node) have an
> explicit description of the connected party/parties. Besides, this looks
> consistent with the bidirectional links in remote-endpoints, which has
> similarities.

In a complex graph, you need to be able to walk from any node to
another node. I don't think that applies here.

> OTOH I agree a single-direction link (i2c extension node to i2c
> adapter) should work, in principle. However there are issues, mainly in
> how an adapter finds out about the extensions when it is probed after
> them.

We've had other cases such as i2c-parent and ddc-i2c-bus for years.
Wouldn't those have the same issue? Maybe they do and just ignored it.
If so, too late to change their DT and the kernel has to solve the
problems there anyways...

> Your proposal of searching the whole tree involves a lot of searches in
> a potentially large tree, even though I don't expect it to happen often
> at least for the use cases I'm aware of.

Right. And the need to do that entirely depends on the I2C core
needing to scan the whole tree. Surely that's not actually the case.
How does adding a device by overlay (as a direct child) work? If the
I2C core just scans the child nodes again, don't we just need to
change it to scan somewhere else? Seems like that would be simple
enough change.

> But, more important, Hervé pointed out an "i2c-parent" property is
> already used for different purposes (i2c muxes). We could choose
> another string but that would be fragile too.

It's the same purpose. Linking an i2c bus to somewhere else in the
tree. I don't see why a connector/overlay is special here.

> One idea is to unambiguously mark i2c bus extension nodes with a
> compatible string:
>
>   connector {
>       i2c_ctrl: i2c-ctrl {
>           compatible = "i2c-bus-extension"; // <-----
>           i2c-parent = <&i2c1>;
>           #address-cells = <1>;
>           #size-cells = <0>;
>       };
>   };
>
> And then implementing a device driver for the i2c bus extension.

I generally will never argue against adding a compatible...

> This would allow to ensure extensions are probed after their adapter
> (thanks to probe deferral) and at that point can register themselves at
> the adapter. In other words the device driver core would provide the
> synchronization between adapter, bus extension, and devices on the bus
> extension.

Can't the parent (the connector node) driver do the same thing and
defer if any i2c-parent phandles drivers aren't probed?

> A different option is to only have the "i2c-parent" phandle in the
> extension node and nothing else in DT (no bidirectional link, no
> compatible string), without any full-tree searches.
>
> On the implementation side, the connector driver when probing would
> register the extension nodes at the I2C core, which would maintain a
> list of extension nodes. This is important when the connector probes
> first. Then when any adapter probes the core would iterate over the
> list to check whether the newly-probed adapter is pointed to by one of
> the registered bus extensions, and then start populating the devices on
> the matching bus extension(s).
>
> A lot of care would have to be put in the disconnection path and while
> removing any bus extension from the global list, which could race with
> the I2C core using the list itself. The drive core wouldn't do it for
> us for free.

I'll defer to Wolfram on I2C core implementation...


Rob

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Wolfram Sang]

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

Hi,

> > A different option is to only have the "i2c-parent" phandle in the
> > extension node and nothing else in DT (no bidirectional link, no
> > compatible string), without any full-tree searches.
> >
> > On the implementation side, the connector driver when probing would
> > register the extension nodes at the I2C core, which would maintain a
> > list of extension nodes. This is important when the connector probes
> > first. Then when any adapter probes the core would iterate over the
> > list to check whether the newly-probed adapter is pointed to by one of
> > the registered bus extensions, and then start populating the devices on
> > the matching bus extension(s).
> >
> > A lot of care would have to be put in the disconnection path and while
> > removing any bus extension from the global list, which could race with
> > the I2C core using the list itself. The drive core wouldn't do it for
> > us for free.
> 
> I'll defer to Wolfram on I2C core implementation...

One input already before we dive into the unconference. I don't want to
maintain the above solution, i.e. handling lists with sublte race issues
which could be (and should be IMO) handled by the driver core anyhow.

See you soon, may the A/V-setup be with us,

   Wolfram


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

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Herve Codina]

Hi Wolfram,

On Tue, 26 Aug 2025 16:03:45 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:

> Hi,
> 
> > > A different option is to only have the "i2c-parent" phandle in the
> > > extension node and nothing else in DT (no bidirectional link, no
> > > compatible string), without any full-tree searches.
> > >
> > > On the implementation side, the connector driver when probing would
> > > register the extension nodes at the I2C core, which would maintain a
> > > list of extension nodes. This is important when the connector probes
> > > first. Then when any adapter probes the core would iterate over the
> > > list to check whether the newly-probed adapter is pointed to by one of
> > > the registered bus extensions, and then start populating the devices on
> > > the matching bus extension(s).
> > >
> > > A lot of care would have to be put in the disconnection path and while
> > > removing any bus extension from the global list, which could race with
> > > the I2C core using the list itself. The drive core wouldn't do it for
> > > us for free.  
> > 
> > I'll defer to Wolfram on I2C core implementation...  
> 
> One input already before we dive into the unconference. I don't want to
> maintain the above solution, i.e. handling lists with sublte race issues
> which could be (and should be IMO) handled by the driver core anyhow.

Wolfram, could it be ok if this list is not global but related to the
adapter the extension belongs to?

If the list is really a nogo, registering extensions cannot be done and
so with:
 1) "i2c-parent" phandle and the compatible string "i2c-bus-extension" in
    the extension node.
 2) No registering extensions capabilities available

the only solution I see is to parse the full DT in order to find extension
nodes when we need to register adapter children (adapter probe() step).

A matching extension node will be a node where:
 1) compatible = "i2c-bus-extension"
 2) "i2c-parent" phandle points to the expected adapter.

Wolfram, is it a solution you can accept?

Best regards,
Hervé

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Wolfram Sang]

Hi Hervé,

> the only solution I see is to parse the full DT in order to find extension
> nodes when we need to register adapter children (adapter probe() step).
> 
> A matching extension node will be a node where:
>  1) compatible = "i2c-bus-extension"
>  2) "i2c-parent" phandle points to the expected adapter.

Would that be so bad? It will not be done often, or?

All the best,

   Wolfram

Re: [PATCH v3 1/1] schemas: i2c: Introduce I2C bus extensions

[Herve Codina]

Hi Wolfram,

On Fri, 29 Aug 2025 12:58:06 +0200
Wolfram Sang <wsa+renesas@sang-engineering.com> wrote:

> Hi Hervé,
> 
> > the only solution I see is to parse the full DT in order to find extension
> > nodes when we need to register adapter children (adapter probe() step).
> > 
> > A matching extension node will be a node where:
> >  1) compatible = "i2c-bus-extension"
> >  2) "i2c-parent" phandle points to the expected adapter.  
> 
> Would that be so bad? It will not be done often, or?

Ok I will propose a binding update in that sense (dtschema repo) and an
implementation (kernel repo).

Best regards,
Hervé