[PATCH v4 0/2] Add xSPI support for RZ/T2H and RZ/N2H SoCs

[PATCH v4 0/2] Add xSPI support for RZ/T2H and RZ/N2H SoCs

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Hi All,

Add support for the xSPI (Extended SPI) Interface on Renesas RZ/T2H and
RZ/N2H SoCs. The xSPI IP on these SoCs is identical to that found on the
RZ/G3E SoC.

v3->v4:
- Added restriction for resets and reset-names properties to have
  maxItems: 1 for RZ/T2H and RZ/N2H SoCs, since they only have a
  single reset.

v2->v3:
- Used RZ/G3E comptiable as a fallback compatible for
  RZ/T2H and RZ/N2H SoCs since the xSPI IP is identical.
- Updated commit message to reflect that the xSPI IP is
  identical between RZ/G3E, RZ/T2H, and RZ/N2H SoCs.
- Dropped RB tag from Rob for patch#1.
- Dropped driver changes for RZ/T2H and RZ/N2H SoCs since
  the xSPI IP is compatible to RZ/G3E.

v1->v2:
- Add RB tag from Rob for the dt-bindings patch.
- Add RB tag from Wolfram for the rpc-if duplicate device name patch.
- Added xspi_info_r9a09g077 for RZ/T2H with type XSPI_RZ_T2H instead
  of reusing xspi_info_r9a09g047 with type XSPI_RZ_G3E, to allow for
  better differentiation in the future if needed.

v2: https://lore.kernel.org/all/20260327174245.3947213-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
v1: https://lore.kernel.org/all/20260310212927.3372410-1-prabhakar.mahadev-lad.rj@bp.renesas.com/

Note, patches are rebased on top of next-20260508.

Cheers,
Prabhakar

Lad Prabhakar (2):
  dt-bindings: memory: renesas,rzg3e-xspi: Add RZ/T2H and RZ/N2H support
  memory: renesas-rpc-if: Fix duplicate device name on multi-instance
    platforms

 .../renesas,rzg3e-xspi.yaml                   | 60 +++++++++++++++----
 drivers/memory/renesas-rpc-if.c               |  2 +-
 2 files changed, 51 insertions(+), 11 deletions(-)

-- 
2.54.0

[PATCH v4 1/2] dt-bindings: memory: renesas,rzg3e-xspi: Add RZ/T2H and RZ/N2H support

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Document xSPI controller found on the Renesas RZ/T2H and RZ/N2H SoCs.
The xSPI IP on these SoCs is identical to that found on the RZ/G3E SoC.

The RZ/G3E HW manual (Rev.1.15) references bridge channel 1 and its
bits, however the hardware actually supports only a single bridge
channel (channel 0), matching the RZ/T2H design. The references to
channel 1 and its configuration bits will be corrected in a future
revision of the HW manual.

Update clock/reset constraints to handle the SoC differences.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v3->v4:
- Added restriction for resets and reset-names properties to have
  maxItems: 1 for RZ/T2H and RZ/N2H SoCs, since they only have a
  single reset.

v2->v3:
- Used RZ/G3E comptiable as a fallback compatible for
  RZ/T2H and RZ/N2H SoCs since the xSPI IP is identical.
- Updated commit message to reflect that the xSPI IP is
 identical between RZ/G3E, RZ/T2H, and RZ/N2H SoCs.
- Dropped RB tag from Rob due to above changes.

v1->v2:
- Add RB tag from Rob for the dt-bindings patch.
---
 .../renesas,rzg3e-xspi.yaml                   | 60 +++++++++++++++----
 1 file changed, 50 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
index 7a84f5bb7284..cdeca4c795f3 100644
--- a/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
@@ -30,6 +30,8 @@ properties:
           - enum:
               - renesas,r9a09g056-xspi  # RZ/V2N
               - renesas,r9a09g057-xspi  # RZ/V2H(P)
+              - renesas,r9a09g077-xspi  # RZ/T2H
+              - renesas,r9a09g087-xspi  # RZ/N2H
           - const: renesas,r9a09g047-xspi
 
   reg:
@@ -53,28 +55,38 @@ properties:
       - const: err_pulse
 
   clocks:
-    items:
-      - description: AHB clock
-      - description: AXI clock
-      - description: SPI clock
-      - description: Double speed SPI clock
+    oneOf:
+      - items:
+          - description: AHB clock
+          - description: AXI clock
+          - description: SPI clock
+          - description: Double speed SPI clock
+      - items:
+          - description: AHB clock
+          - description: SPI clock
 
   clock-names:
-    items:
-      - const: ahb
-      - const: axi
-      - const: spi
-      - const: spix2
+    oneOf:
+      - items:
+          - const: ahb
+          - const: axi
+          - const: spi
+          - const: spix2
+      - items:
+          - const: ahb
+          - const: spi
 
   power-domains:
     maxItems: 1
 
   resets:
+    minItems: 1
     items:
       - description: Hardware reset
       - description: AXI reset
 
   reset-names:
+    minItems: 1
     items:
       - const: hresetn
       - const: aresetn
@@ -109,6 +121,34 @@ required:
   - '#address-cells'
   - '#size-cells'
 
+if:
+  properties:
+    compatible:
+      contains:
+        enum:
+          - renesas,r9a09g077-xspi
+          - renesas,r9a09g087-xspi
+then:
+  properties:
+    clocks:
+      maxItems: 2
+    clock-names:
+      maxItems: 2
+    resets:
+      maxItems: 1
+    reset-names:
+      maxItems: 1
+else:
+  properties:
+    clocks:
+      minItems: 4
+    clock-names:
+      minItems: 4
+    resets:
+      minItems: 2
+    reset-names:
+      minItems: 2
+
 unevaluatedProperties: false
 
 examples:
-- 
2.54.0

[PATCH v4 2/2] memory: renesas-rpc-if: Fix duplicate device name on multi-instance platforms

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

On platforms with multiple xSPI instances, the driver fails to probe
additional instances due to duplicate sysfs entries:

  [   86.878242] sysfs: cannot create duplicate filename '/bus/platform/devices/rpc-if-spi'

This occurs because platform_device_alloc() uses pdev->id for the device
ID, which may be PLATFORM_DEVID_NONE (-1) for multiple instances, causing
all instances to attempt registration with the same name.

Fix this by using PLATFORM_DEVID_AUTO instead, which automatically assigns
unique IDs to each device instance, allowing multiple xSPI controllers to
coexist without naming conflicts.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
v2->v4:
- No change

v1->v2:
- Add RB tag from Wolfram.
---
 drivers/memory/renesas-rpc-if.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c
index 0fb568456164..3755956ae906 100644
--- a/drivers/memory/renesas-rpc-if.c
+++ b/drivers/memory/renesas-rpc-if.c
@@ -1034,7 +1034,7 @@ static int rpcif_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(rpc->spi_clk),
 				     "cannot get enabled spi clk\n");
 
-	vdev = platform_device_alloc(name, pdev->id);
+	vdev = platform_device_alloc(name, PLATFORM_DEVID_AUTO);
 	if (!vdev)
 		return -ENOMEM;
 	vdev->dev.parent = dev;
-- 
2.54.0

Re: [PATCH v4 1/2] dt-bindings: memory: renesas,rzg3e-xspi: Add RZ/T2H and RZ/N2H support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The new SoCs claim fallback compatibility with `renesas,r9a09g047-xspi` but provide strictly fewer hardware resources than the fallback schema previously mandated.
- [Medium] The `else` block enforces a known-incorrect `minItems: 4` constraint on the base `renesas,r9a09g047-xspi` compatible, contradicting the hardware reality described in the commit message.
--

commit 53ce1d0b1afc85c1adf4f55123b53c081bc04767
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

dt-bindings: memory: renesas,rzg3e-xspi: Add RZ/T2H and RZ/N2H support

Document the xSPI controller found on the Renesas RZ/T2H and RZ/N2H SoCs.
The patch updates clock and reset constraints to handle SoC differences,
noting that the RZ/G3E hardware actually only supports a single bridge
channel despite manual references.

> diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
> index 7a84f5bb7284e..cdeca4c795f3a 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
> +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
> @@ -30,6 +30,8 @@ properties:
>            - enum:
>                - renesas,r9a09g056-xspi  # RZ/V2N
>                - renesas,r9a09g057-xspi  # RZ/V2H(P)
> +              - renesas,r9a09g077-xspi  # RZ/T2H
> +              - renesas,r9a09g087-xspi  # RZ/N2H
>            - const: renesas,r9a09g047-xspi

Could this cause a regression since the new SoCs claim fallback
compatibility with renesas,r9a09g047-xspi, but provide strictly fewer
hardware resources than the fallback schema previously mandated?

A fallback compatible string asserts that an unmodified legacy OS driver for
the fallback SoC can successfully drive the new hardware. Prior to this patch,
the schema for renesas,r9a09g047-xspi mandated 4 clocks and 2 resets. The new
if/then block restricts the new SoCs to only 2 clocks and 1 reset.

While the current Linux driver handles this gracefully by using
devm_clk_get_optional_enabled(), Device Tree bindings are strictly
OS-agnostic. An older OS driver written strictly to the fallback's original
schema might attempt to acquire the previously mandatory axi/spix2 clocks and
aresetn reset, resulting in a probe failure.

Could the fallback's constraints be relaxed instead, or should SoCs providing
fewer resources avoid claiming fallback compatibility with a more
resource-demanding SoC?

[ ... ]

> @@ -109,6 +121,34 @@ required:
>    - '#address-cells'
>    - '#size-cells'
>  
> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        enum:
> +          - renesas,r9a09g077-xspi
> +          - renesas,r9a09g087-xspi
> +then:
> +  properties:
> +    clocks:
> +      maxItems: 2
> +    clock-names:
> +      maxItems: 2
> +    resets:
> +      maxItems: 1
> +    reset-names:
> +      maxItems: 1
> +else:
> +  properties:
> +    clocks:
> +      minItems: 4
> +    clock-names:
> +      minItems: 4
> +    resets:
> +      minItems: 2
> +    reset-names:
> +      minItems: 2

Does this else block introduce a regression by enforcing a known-incorrect
minItems constraint on the base renesas,r9a09g047-xspi compatible?

The commit message explicitly states that the RZ/G3E hardware actually only
supports a single bridge channel, matching the RZ/T2H design. However, the
patch adds an else block that strictly enforces minItems: 4 for clocks and
minItems: 2 for resets on all variants not listed in the if block. This
cements a known-incorrect hardware description into the schema.

When the RZ/G3E devicetrees are eventually corrected to reflect the 2-clock
hardware reality as promised, will they immediately fail schema validation?
Would relaxing the else block correctly allow RZ/G3E to use either the legacy
4-item or the correct 2-item configurations?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515115202.1515577-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=1