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> 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?
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.