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

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

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               |  3 +-
 2 files changed, 51 insertions(+), 12 deletions(-)

-- 
2.53.0

[PATCH 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>
---
 .../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

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

[Rob Herring (Arm)]

On Tue, 10 Mar 2026 21:29:25 +0000, Prabhakar wrote:
> 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>
> ---
>  .../renesas,rzg3e-xspi.yaml                   | 60 +++++++++++++++----
>  1 file changed, 49 insertions(+), 11 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH 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>
---
 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

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

[Wolfram Sang]

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

On Tue, Mar 10, 2026 at 09:29:26PM +0000, Prabhakar wrote:
> 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>

Sounds reasonable to me.

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


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

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

[Prabhakar]

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

Add xSPI (Extended SPI) support for the RZ/T2H SoC. The xSPI IP on RZ/T2H
is closely related to the RZ/G3E variant with some register bit differences
in the configuration registers.

Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
to bind correctly on RZ/T2H while the register differences can be handled
in future updates as the affected configuration registers are not currently
accessed by the driver.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 drivers/memory/renesas-rpc-if.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/memory/renesas-rpc-if.c b/drivers/memory/renesas-rpc-if.c
index 3755956ae906..028bd3b4b9e3 100644
--- a/drivers/memory/renesas-rpc-if.c
+++ b/drivers/memory/renesas-rpc-if.c
@@ -1145,6 +1145,7 @@ static const struct rpcif_info xspi_info_r9a09g047 = {
 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_r9a09g047 },
 	{ .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 },
-- 
2.53.0

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

[Wolfram Sang]

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


> Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
> reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
> to bind correctly on RZ/T2H while the register differences can be handled
> in future updates as the affected configuration registers are not currently
> accessed by the driver.

This sounds fragile to me. Can you add a comment somewhere in the driver
or headers so people wanting to use these registers will find out that
the SoCs are not compatible anymore?


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

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

[Krzysztof Kozlowski]

On 16/03/2026 15:16, Wolfram Sang wrote:
> 
>> Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
>> reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
>> to bind correctly on RZ/T2H while the register differences can be handled
>> in future updates as the affected configuration registers are not currently
>> accessed by the driver.
> 
> This sounds fragile to me. Can you add a comment somewhere in the driver
> or headers so people wanting to use these registers will find out that
> the SoCs are not compatible anymore?

IMO, this patch is not needed. If you need to handle differences in
registers, then you add dedicated OF data.

The change here (with the bindings) is actually confusing, because
effectively it says two contradictory statements:
1. Driver patch: devices are different but they are compatible in
meaning of DT,
2. Bindings: devices are not compatible

So you need to decide which above, but not both.

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

Best regards,
Krzysztof

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

[Geert Uytterhoeven]

Hi Krzysztof,

On Mon, 16 Mar 2026 at 15:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 16/03/2026 15:16, Wolfram Sang wrote:
> >> Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
> >> reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
> >> to bind correctly on RZ/T2H while the register differences can be handled
> >> in future updates as the affected configuration registers are not currently
> >> accessed by the driver.
> >
> > This sounds fragile to me. Can you add a comment somewhere in the driver
> > or headers so people wanting to use these registers will find out that
> > the SoCs are not compatible anymore?
>
> IMO, this patch is not needed. If you need to handle differences in
> registers, then you add dedicated OF data.
>
> The change here (with the bindings) is actually confusing, because
> effectively it says two contradictory statements:
> 1. Driver patch: devices are different but they are compatible in
> meaning of DT,
> 2. Bindings: devices are not compatible
>
> So you need to decide which above, but not both.
>
> Eventually provide extensive arguments in terms of how DT understands
> compatibility.

I disagree.  Using the same of_data can does not mean the devices are
100% compatible.  It can also mean that the devices are different, but
  a) The differences are not handled yet, because the extra features of
     one variant (or both variants)  are not yet supported by the driver,
  b) The differences are not handled explicitly, but implicitly,
     or elsewhere.
     E.g. the different number of resets is handled implicitly through
     devm_reset_control_array_get_exclusive().

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

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

[Krzysztof Kozlowski]

On 16/03/2026 15:34, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Mon, 16 Mar 2026 at 15:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 16/03/2026 15:16, Wolfram Sang wrote:
>>>> Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
>>>> reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
>>>> to bind correctly on RZ/T2H while the register differences can be handled
>>>> in future updates as the affected configuration registers are not currently
>>>> accessed by the driver.
>>>
>>> This sounds fragile to me. Can you add a comment somewhere in the driver
>>> or headers so people wanting to use these registers will find out that
>>> the SoCs are not compatible anymore?
>>
>> IMO, this patch is not needed. If you need to handle differences in
>> registers, then you add dedicated OF data.
>>
>> The change here (with the bindings) is actually confusing, because
>> effectively it says two contradictory statements:
>> 1. Driver patch: devices are different but they are compatible in
>> meaning of DT,
>> 2. Bindings: devices are not compatible
>>
>> So you need to decide which above, but not both.
>>
>> Eventually provide extensive arguments in terms of how DT understands
>> compatibility.
> 
> I disagree.  Using the same of_data can does not mean the devices are
> 100% compatible.  It can also mean that the devices are different, but

I did not say 100% compatible. I said compatible.

>   a) The differences are not handled yet, because the extra features of
>      one variant (or both variants)  are not yet supported by the supported by the driver
So that's why I mentioned how DT understands compatibility. Above does
not matter, sorry.

Extra features means subset/superset.

>   b) The differences are not handled explicitly, but implicitly,
>      or elsewhere.
>      E.g. the different number of resets is handled implicitly through
>      devm_reset_control_array_get_exclusive().

Still not an argument in meaning of DT compatibility. Implementation
uses the same ABI (through devm_reset_control_array_get_exclusive),
right? So devices are compatible for Linux kernel.

Best regards,
Krzysztof

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

[Geert Uytterhoeven]

Hi Krzysztof,

On Mon, 16 Mar 2026 at 15:46, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 16/03/2026 15:34, Geert Uytterhoeven wrote:
> > On Mon, 16 Mar 2026 at 15:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> On 16/03/2026 15:16, Wolfram Sang wrote:
> >>>> Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
> >>>> reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
> >>>> to bind correctly on RZ/T2H while the register differences can be handled
> >>>> in future updates as the affected configuration registers are not currently
> >>>> accessed by the driver.
> >>>
> >>> This sounds fragile to me. Can you add a comment somewhere in the driver
> >>> or headers so people wanting to use these registers will find out that
> >>> the SoCs are not compatible anymore?
> >>
> >> IMO, this patch is not needed. If you need to handle differences in
> >> registers, then you add dedicated OF data.
> >>
> >> The change here (with the bindings) is actually confusing, because
> >> effectively it says two contradictory statements:
> >> 1. Driver patch: devices are different but they are compatible in
> >> meaning of DT,
> >> 2. Bindings: devices are not compatible
> >>
> >> So you need to decide which above, but not both.
> >>
> >> Eventually provide extensive arguments in terms of how DT understands
> >> compatibility.
> >
> > I disagree.  Using the same of_data can does not mean the devices are
> > 100% compatible.  It can also mean that the devices are different, but
>
> I did not say 100% compatible. I said compatible.

Fair enough.

> >   a) The differences are not handled yet, because the extra features of
> >      one variant (or both variants)  are not yet supported by the supported by the driver
> So that's why I mentioned how DT understands compatibility. Above does
> not matter, sorry.
>
> Extra features means subset/superset.

I haven't looked at the differences between the two variants here,
but I doubt one of them is a superset of the other. Probably both are
supersets of a common subvariant that doesn't really exist ;-)

> >   b) The differences are not handled explicitly, but implicitly,
> >      or elsewhere.
> >      E.g. the different number of resets is handled implicitly through
> >      devm_reset_control_array_get_exclusive().
>
> Still not an argument in meaning of DT compatibility. Implementation
> uses the same ABI (through devm_reset_control_array_get_exclusive),
> right? So devices are compatible for Linux kernel.

Linux is not the only user of DT.

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

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

[Krzysztof Kozlowski]

On 16/03/2026 16:02, Geert Uytterhoeven wrote:
> 
>>>   a) The differences are not handled yet, because the extra features of
>>>      one variant (or both variants)  are not yet supported by the supported by the driver
>> So that's why I mentioned how DT understands compatibility. Above does
>> not matter, sorry.
>>
>> Extra features means subset/superset.
> 
> I haven't looked at the differences between the two variants here,
> but I doubt one of them is a superset of the other. Probably both are
> supersets of a common subvariant that doesn't really exist ;-)

That could be the argument. Consider also that we don't care if
superset/subset is a real, design decision. If you have two independent
companies making something working with the same interface, they are
compatible. If one adds one more feature, you have superset/subset.

And we already have some examples of this for simpler devices in hwmon
and/or iio.

> 
>>>   b) The differences are not handled explicitly, but implicitly,
>>>      or elsewhere.
>>>      E.g. the different number of resets is handled implicitly through
>>>      devm_reset_control_array_get_exclusive().
>>
>> Still not an argument in meaning of DT compatibility. Implementation
>> uses the same ABI (through devm_reset_control_array_get_exclusive),
>> right? So devices are compatible for Linux kernel.
> 
> Linux is not the only user of DT.

With such argument (implied: "there is an user which cannot use that
compatibility"), nothing would be ever compatible except devices being
identical. If you cannot find such user, you can write a driver which on
purpose will be incompatible and bring it as an argument.

If there is known incompatible implementation, please mention it.
Otherwise the implementation here kind of rules devices are compatible.
Assuming implementation is working and to some extend usable, e.g.
complete set of some features.

Best regards,
Krzysztof

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

[Lad, Prabhakar]

Hi Wolfram,

Thank you for the review.

On Mon, Mar 16, 2026 at 2:16 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
>
> > Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
> > reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
> > to bind correctly on RZ/T2H while the register differences can be handled
> > in future updates as the affected configuration registers are not currently
> > accessed by the driver.
>
> This sounds fragile to me. Can you add a comment somewhere in the driver
> or headers so people wanting to use these registers will find out that
> the SoCs are not compatible anymore?
>
I could but they would stay unused.

For example, consider the COMCFG register.
On RZ/G3E, bits 0-1 are used to control the `Channel arbitration mode`
On RZ/T2H, bits 0-1 are marked as reserved and the write value should be 0.

Currently the COMCFG register is not handled in the driver. Similarly
it's the same for other differences.

Can you please suggest how to handle this case.

RZ/G3E HW manual,
https://www.renesas.com/en/document/mah/rzg3e-group-users-manual-hardware
RZ/T2H HW manual,
https://www.renesas.com/en/document/mah/rzt2h-and-rzn2h-groups-users-manual-hardware

Cheers,
Prabhakar

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

[Lad, Prabhakar]

Hi Wolfram,

On Wed, Mar 18, 2026 at 2:03 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> Hi Wolfram,
>
> Thank you for the review.
>
> On Mon, Mar 16, 2026 at 2:16 PM Wolfram Sang
> <wsa+renesas@sang-engineering.com> wrote:
> >
> >
> > > Add a new compatible string "renesas,r9a09g077-xspi" for RZ/T2H while
> > > reusing the existing xspi_info_r9a09g047 OF data. This allows the driver
> > > to bind correctly on RZ/T2H while the register differences can be handled
> > > in future updates as the affected configuration registers are not currently
> > > accessed by the driver.
> >
> > This sounds fragile to me. Can you add a comment somewhere in the driver
> > or headers so people wanting to use these registers will find out that
> > the SoCs are not compatible anymore?
> >
> I could but they would stay unused.
>
> For example, consider the COMCFG register.
> On RZ/G3E, bits 0-1 are used to control the `Channel arbitration mode`
> On RZ/T2H, bits 0-1 are marked as reserved and the write value should be 0.
>
> Currently the COMCFG register is not handled in the driver. Similarly
> it's the same for other differences.
>
> Can you please suggest how to handle this case.
>
Would adding SoC specific data like below be OK?

static const struct rpcif_info xspi_info_r9a09g077 = {
       .regmap_config = &xspi_regmap_config,
       .impl = &xspi_impl,
       .type = XSPI_RZ_T2H,
};


{ .compatible = "renesas,r9a09g077-xspi", .data = &xspi_info_r9a09g077 },

Cheers,
Prabhakar