Message-Id: <20250729-spi-bus-extension-v1-0-b20c73f2161a@beagleboard.org>
Date: Tue, 29 Jul 2025 15:20:59 +0530
From: Ayush Singh <ayush@...gleboard.org>
To: Mark Brown <broonie@...nel.org>, herve.codina@...tlin.com, 
 luca.ceresoli@...tlin.com, conor+dt@...nel.org, 
 Jason Kridner <jkridner@...gleboard.org>, 
 Deepak Khatri <lorforlinux@...gleboard.org>, Dhruva Gole <d-gole@...com>, 
 Robert Nelson <robertcnelson@...gleboard.org>, Andrew Davis <afd@...com>, 
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>
Cc: linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org, 
 devicetree@...r.kernel.org, Ayush Singh <ayush@...gleboard.org>
Subject: [PATCH 0/4] spi: Introduce spi bus extensions

This patch series is basically an SPI version of i2c-bus-extension patch
series [0].

The big picture behind this RFC series is to support a Linux device
with a connector to physically add and remove an add-on to/from the
main device to augment its features at runtime, adding devices on
non-discoverable busses, using device tree overlays.

The related big picture has been already presented in
  - the 'Add support for GE SUNH hot-pluggable connector' series [0]
  - the 'Runtime hotplug on non-discoverable busses with device tree
    overlays' talk at Linux Plumbers Conference 2024 [1].

This series focuses on the SPI related part.

An spi bus is wired to the connector and allows an add-on board to
connect additional spi devices to this bus.

When device tree nodes are added, the SPI core tries to probe client
devices based on the classic DT structure:

  spi@...d0000 {
      some-client@42 { compatible = "xyz,blah"; ... };
  };

However for hotplug connectors described via device tree overlays [1]
there is additional level of indirection, which is needed to decouple
the overlay and the base tree:

  --- base device tree ---

  spi1: spi@...d0000 {
      compatible = "xyz,spi-ctrl";
      spi-bus-extension@0 {
          spi-bus = <&spi_ctrl>;
      };
      ...
  };

  spi5: spi@...e0000 {
      compatible = "xyz,spi-ctrl";
      spi-bus-extension@0 {
          spi-bus = <&spi-sensors>;
      };
      ...
  };

  connector {
      spi_ctrl: spi-ctrl {
          spi-parent = <&spi1>;
          #address-cells = <1>;
          #size-cells = <0>;
      };

      spi-sensors {
          spi-parent = <&spi5>;
          #address-cells = <1>;
          #size-cells = <0>;
      };
  };

  --- device tree overlay ---

  ...
  // This node will overlay on the spi-ctrl node of the base tree
  spi-ctrl {
      device@1 { compatible = "xyz,foo"; ... };
  };
  ...

  --- resulting device tree ---

  spi1: spi@...d0000 {
      compatible = "xyz,spi-ctrl";
      spi-bus-extension@0 {
          spi-bus = <&spi_ctrl>;
      };
      ...
  };

  spi5: spi@...e0000 {
      compatible = "xyz,spi-ctrl";
      spi-bus-extension@0 {
          spi-bus = <&spi-sensors>;
      };
      ...
  };

  connector {
      spi-ctrl {
          spi-parent = <&spi1>;
          #address-cells = <1>;
          #size-cells = <0>;

          device@1 { compatible = "xyz,foo"; ... };
      };

      spi-sensors {
          spi-parent = <&spi5>;
          #address-cells = <1>;
          #size-cells = <0>;
      };
  };

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

In order to decouple the overlay from the base tree, the SPI adapter
(spi@...d0000) and the extension node (spi-ctrl) are separate nodes.
Rightfully, only the former will probe into an SPI adapter, and it will
do that perhaps during boot, long before overlay insertion or after the
overlay has been inserted for instance if the SPI adapter is remove and
re-probed for whatever reason after the overlay insertion.

The extension node won't probe into an SPI adapter or any other device
or bus, so its subnodes ('device@1') won't be interpreted as SPI
clients by current SPI core code.

The extension node is linked to the adapter node in two ways. The first
one with the spi-bus-extension adapter sub-node and the second one with
the spi-parent property in the extension node itself.

The purpose of those two links is to handle device probing in several
cases.

- First case: Adapter already probed when add-on devices are added

When devices are added by the overlay, an OF change notification is
triggered so that busses can support those new devices.

Going from a newly added device node, the spi-parent property allows to
find the corresponding SPI adapter and register the new SPI client with
this adapter.

The patch 1 in this series proposes modification to handle this case
and, by the nature of the modification, all cases where a phandle refers
an extension node instead of the adapter node itself.

- Second case: Add-on devices already present in device-tree when
  adapter is probed

In this case, everything is already described in the device-tree and
then the adapter is probed.

OF change notifications don't play a role in this case either because
they were never triggered (the overlay was applied by the bootloader)
or they were triggered before the adapter is probed and so were
missed/ignored.

The adapter probe process registers device already described at the
adapter node level (current code) and, thanks to spi-bus-extension
adapter sub-node and its spi-bus property, it can also follow the
extension and registers devices described in those extension nodes.

The patch 2 and 3 in this series proposes modifications to handle this
case.

The patch 4 provides the device-tree bindings for spi-bus-extension and
spi-parent.

I also have a prototype driver with addon-board overlays to see how
combining all the relevant patches looks for support Beagle capes for
PocketBeagle 2 [3]. The tree can be found here [4]. To be more specific,
the base board overlay can be found here [5] and the addon board
(Techlab Cape [6]) overlay can be found here [7].

Best Regards,
Ayush Singh

[0]: https://lore.kernel.org/all/20250205173918.600037-1-herve.codina@bootlin.com/
[1]: https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@bootlin.com/
[2]: https://lpc.events/event/18/contributions/1696/
[3]: https://www.beagleboard.org/boards/pocketbeagle-2
[4]: https://github.com/Ayush1325/linux/commits/beagle-cape-v1/
[5]: https://github.com/Ayush1325/BeagleBoard-DeviceTrees/commit/0d919e3fca9bc134b8593db16d1da9d73bdb794f
[6]: https://www.beagleboard.org/boards/techlab
[7]: https://github.com/Ayush1325/linux/commit/7a6728e35b4b82e94c24a0a9464ab849b8485812

Signed-off-by: Ayush Singh <ayush@...gleboard.org>
---
Ayush Singh (4):
      spi: Follow spi-parent when retrieving a controller from node
      spi: Move children registration in a dedicated function
      spi: Handle spi bus extension
      devicetree: bindings: spi: Introduce SPI bus extensions

 .../devicetree/bindings/spi/spi-controller.yaml    | 66 +++++++++++++++++++++-
 drivers/spi/spi.c                                  | 63 +++++++++++++++++----
 2 files changed, 116 insertions(+), 13 deletions(-)
---
base-commit: d7af19298454ed155f5cf67201a70f5cf836c842
change-id: 20250728-spi-bus-extension-121de5d93b47

Best regards,
-- 
Ayush Singh <ayush@...gleboard.org>

Powered by blists - more mailing lists