[PATCH v2 0/3] Add xSPI support for RZ/T2H and RZ/N2H SoCs

[PATCH v2 0/3] 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 closely related to that found
on the RZ/G3E SoC with some register bit differences in the configuration
registers.

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.

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

Note, patches apply on to of next-20260326

Cheers,
Prabhakar

Lad Prabhakar (3):
  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
  memory: renesas-rpc-if: Add support for RZ/T2H SoC

 .../renesas,rzg3e-xspi.yaml                   | 60 +++++++++++++++----
 drivers/memory/renesas-rpc-if.c               | 13 +++-
 include/memory/renesas-rpc-if.h               |  1 +
 3 files changed, 61 insertions(+), 13 deletions(-)

-- 
2.53.0

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

[Prabhakar]

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

Add device tree binding support for the xSPI Interface on Renesas
RZ/T2H and RZ/N2H SoCs. The xSPI IP on these SoCs is closely related
to that found on the RZ/G3E SoC with some register bit differences
in the configuration registers.

The RZ/T2H variant has a reduced clock configuration, requiring only
the AHB and SPI clocks (without the AXI and spix2 clocks). It also
requires only the hardware reset (hresetn), without the AXI reset
(aresetn).

The RZ/N2H variant is compatible with RZ/T2H and uses the same clock
and reset configuration.

Update the binding schema to accommodate these differences using
conditional constraints based on the compatible string, while
maintaining backward compatibility with existing RZ/G3E and RZ/V2H(P)
implementations.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
v1->v2:
- Add RB tag from Rob for the dt-bindings patch.
---
 .../renesas,rzg3e-xspi.yaml                   | 60 +++++++++++++++----
 1 file changed, 49 insertions(+), 11 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..bf50d90051c9 100644
--- a/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rzg3e-xspi.yaml
@@ -24,7 +24,9 @@ allOf:
 properties:
   compatible:
     oneOf:
-      - const: renesas,r9a09g047-xspi  # RZ/G3E
+      - enum:
+          - renesas,r9a09g047-xspi  # RZ/G3E
+          - renesas,r9a09g077-xspi  # RZ/T2H
 
       - items:
           - enum:
@@ -32,6 +34,10 @@ properties:
               - renesas,r9a09g057-xspi  # RZ/V2H(P)
           - const: renesas,r9a09g047-xspi
 
+      - items:
+          - const: renesas,r9a09g087-xspi # RZ/N2H
+          - const: renesas,r9a09g077-xspi
+
   reg:
     items:
       - description: xSPI registers
@@ -53,28 +59,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 +125,28 @@ required:
   - '#address-cells'
   - '#size-cells'
 
+if:
+  properties:
+    compatible:
+      contains:
+        const: renesas,r9a09g077-xspi
+then:
+  properties:
+    clocks:
+      maxItems: 2
+    clock-names:
+      maxItems: 2
+else:
+  properties:
+    clocks:
+      minItems: 4
+    clock-names:
+      minItems: 4
+    resets:
+      minItems: 2
+    resets-names:
+      minItems: 2
+
 unevaluatedProperties: false
 
 examples:
-- 
2.53.0

[PATCH v2 2/3] 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>
---
v1->v2:
- Add RB tag from Wolfram for the rpc-if duplicate device name patch.
---
 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.53.0

[PATCH v2 3/3] memory: renesas-rpc-if: Add support for RZ/T2H SoC

[Prabhakar]

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

Add support for the xSPI controller found on the Renesas RZ/T2H
(R9A09G077) SoC.

The xSPI IP on RZ/T2H is closely related to the RZ/G3E variant, with
minor differences in some configuration register bits. As these
differences are not currently exercised by the driver, reuse the
existing implementation and regmap configuration.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- 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.
---
 drivers/memory/renesas-rpc-if.c | 11 ++++++++++-
 include/memory/renesas-rpc-if.h |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c
index 3755956ae906..347650698424 100644
--- a/drivers/memory/renesas-rpc-if.c
+++ b/drivers/memory/renesas-rpc-if.c
@@ -211,7 +211,9 @@ int rpcif_sw_init(struct rpcif *rpcif, struct device *dev)
 	rpcif->dev = dev;
 	rpcif->dirmap = rpc->dirmap;
 	rpcif->size = rpc->size;
-	rpcif->xspi = rpc->info->type == XSPI_RZ_G3E;
+	rpcif->xspi = (rpc->info->type == XSPI_RZ_G3E ||
+		       rpc->info->type == XSPI_RZ_T2H);
+
 	return 0;
 }
 EXPORT_SYMBOL(rpcif_sw_init);
@@ -1142,9 +1144,16 @@ static const struct rpcif_info xspi_info_r9a09g047 = {
 	.type = XSPI_RZ_G3E,
 };
 
+static const struct rpcif_info xspi_info_r9a09g077 = {
+	.regmap_config = &xspi_regmap_config,
+	.impl = &xspi_impl,
+	.type = XSPI_RZ_T2H,
+};
+
 static const struct of_device_id rpcif_of_match[] = {
 	{ .compatible = "renesas,r8a7796-rpc-if", .data = &rpcif_info_r8a7796 },
 	{ .compatible = "renesas,r9a09g047-xspi", .data = &xspi_info_r9a09g047 },
+	{ .compatible = "renesas,r9a09g077-xspi", .data = &xspi_info_r9a09g077 },
 	{ .compatible = "renesas,rcar-gen3-rpc-if", .data = &rpcif_info_gen3 },
 	{ .compatible = "renesas,rcar-gen4-rpc-if", .data = &rpcif_info_gen4 },
 	{ .compatible = "renesas,rzg2l-rpc-if", .data = &rpcif_info_rz_g2l },
diff --git a/include/memory/renesas-rpc-if.h b/include/memory/renesas-rpc-if.h
index 53663c4e5ae3..39810d2db095 100644
--- a/include/memory/renesas-rpc-if.h
+++ b/include/memory/renesas-rpc-if.h
@@ -62,6 +62,7 @@ enum rpcif_type {
 	RPCIF_RCAR_GEN4,
 	RPCIF_RZ_G2L,
 	XSPI_RZ_G3E,
+	XSPI_RZ_T2H,
 };
 
 struct rpcif {
-- 
2.53.0

Re: [PATCH v2 3/3] memory: renesas-rpc-if: Add support for RZ/T2H SoC

[Krzysztof Kozlowski]

On 27/03/2026 18:42, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> 
> Add support for the xSPI controller found on the Renesas RZ/T2H
> (R9A09G077) SoC.
> 
> The xSPI IP on RZ/T2H is closely related to the RZ/G3E variant, with
> minor differences in some configuration register bits. As these
> differences are not currently exercised by the driver, reuse the
> existing implementation and regmap configuration.
> 
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - 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.

I see you tried to improve the description, but I have the same
concerns. You added now bunch of dead code to mimic lack of
compatibility, but it does not change the fact the code is 100%
compatible in the meaning of DT.

Let me repeat the question from v1:

"Eventually provide extensive arguments in terms of how DT understands
compatibility."

And if you answer like Geert did last time: "differences are not handled
yet" or "new features are not yet implemented" then you will get the
same answer.

Best regards,
Krzysztof