Add support for the Renesas RZ/N1D400 QSPI controller.

This SoC is identified in the bindings with its other name: r9a06g032.
It is part of the RZ/N1 family, which contains a "D" and a "S"
variant. IPs in this SoC are typically described using 3
compatibles (the SoC specific compatible, the family compatible, and the
original Cadence IP compatible), follow this convention.

Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
---
 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
index 53a52fb8b819..62948990defb 100644
--- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
+++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -80,6 +80,10 @@ properties:
           # controllers are meant to be used with flashes of all kinds,
           # ie. also NAND flashes, not only NOR flashes.
           - const: cdns,qspi-nor
+      - items:
+          - const: renesas,r9a06g032-qspi
+          - const: renesas,rzn1-qspi
+          - const: cdns,qspi-nor
       - const: cdns,qspi-nor
         deprecated: true
 

-- 
2.51.1

Hi Miquel,

On Thu, 15 Jan 2026 at 10:25, Miquel Raynal (Schneider Electric)
<miquel.raynal@bootlin.com> wrote:
> Add support for the Renesas RZ/N1D400 QSPI controller.
>
> This SoC is identified in the bindings with its other name: r9a06g032.
> It is part of the RZ/N1 family, which contains a "D" and a "S"
> variant. IPs in this SoC are typically described using 3
> compatibles (the SoC specific compatible, the family compatible, and the
> original Cadence IP compatible), follow this convention.
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>

Thanks for your patch!

> --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> @@ -80,6 +80,10 @@ properties:
>            # controllers are meant to be used with flashes of all kinds,
>            # ie. also NAND flashes, not only NOR flashes.
>            - const: cdns,qspi-nor
> +      - items:
> +          - const: renesas,r9a06g032-qspi
> +          - const: renesas,rzn1-qspi
> +          - const: cdns,qspi-nor

Doesn't the need for (at least) the CQSPI_NO_INDIRECT_MODE flag mean
that this device is not compatible with cdns,qspi-nor, and thus the
cdns,qspi-nor fallback must not be used?

>        - const: cdns,qspi-nor
>          deprecated: true
>

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

Hello Geert,

>> --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
>> +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
>> @@ -80,6 +80,10 @@ properties:
>>            # controllers are meant to be used with flashes of all kinds,
>>            # ie. also NAND flashes, not only NOR flashes.
>>            - const: cdns,qspi-nor
>> +      - items:
>> +          - const: renesas,r9a06g032-qspi
>> +          - const: renesas,rzn1-qspi
>> +          - const: cdns,qspi-nor
>
> Doesn't the need for (at least) the CQSPI_NO_INDIRECT_MODE flag mean
> that this device is not compatible with cdns,qspi-nor, and thus the
> cdns,qspi-nor fallback must not be used?

I understand the question. It is true that I use driver data to limit
the number of features the IP can use and this data is associated to the
Renesas compatible, but I believe all other flavours of this IP would
also not work without driver data attached to their front
compatible. None of the SoCs with the Cadence QSPI IP actually would run
without their own driver data. For me the fallback compatible is
relevant because it describes the hardware as "this is a derivative of
the Cadence controller" (and it is clearly the case, and this is also
mentioned in the reference manual), even though I agree using
cdns,qspi-nor would definitely not work alone. But again, none of the
other flavours would anyway.

Thanks,
Miquèl

On Fri, Jan 16, 2026 at 10:39:21AM +0100, Miquel Raynal wrote:
> Hello Geert,
> 
> >> --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> >> +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
> >> @@ -80,6 +80,10 @@ properties:
> >>            # controllers are meant to be used with flashes of all kinds,
> >>            # ie. also NAND flashes, not only NOR flashes.
> >>            - const: cdns,qspi-nor
> >> +      - items:
> >> +          - const: renesas,r9a06g032-qspi
> >> +          - const: renesas,rzn1-qspi
> >> +          - const: cdns,qspi-nor
> >
> > Doesn't the need for (at least) the CQSPI_NO_INDIRECT_MODE flag mean
> > that this device is not compatible with cdns,qspi-nor, and thus the
> > cdns,qspi-nor fallback must not be used?
> 
> I understand the question. It is true that I use driver data to limit
> the number of features the IP can use and this data is associated to the
> Renesas compatible, but I believe all other flavours of this IP would
> also not work without driver data attached to their front
> compatible. None of the SoCs with the Cadence QSPI IP actually would run
> without their own driver data. For me the fallback compatible is
> relevant because it describes the hardware as "this is a derivative of
> the Cadence controller" (and it is clearly the case, and this is also
> mentioned in the reference manual), even though I agree using
> cdns,qspi-nor would definitely not work alone. But again, none of the
> other flavours would anyway.

Fallbacks should be usable on their own. We've generally moved away from 
having these generic licensed IP compatibles because they always have 
per platform changes.

Rob

>> >> +      - items:
>> >> +          - const: renesas,r9a06g032-qspi
>> >> +          - const: renesas,rzn1-qspi
>> >> +          - const: cdns,qspi-nor
>> >
>> > Doesn't the need for (at least) the CQSPI_NO_INDIRECT_MODE flag mean
>> > that this device is not compatible with cdns,qspi-nor, and thus the
>> > cdns,qspi-nor fallback must not be used?
>> 
>> I understand the question. It is true that I use driver data to limit
>> the number of features the IP can use and this data is associated to the
>> Renesas compatible, but I believe all other flavours of this IP would
>> also not work without driver data attached to their front
>> compatible. None of the SoCs with the Cadence QSPI IP actually would run
>> without their own driver data. For me the fallback compatible is
>> relevant because it describes the hardware as "this is a derivative of
>> the Cadence controller" (and it is clearly the case, and this is also
>> mentioned in the reference manual), even though I agree using
>> cdns,qspi-nor would definitely not work alone. But again, none of the
>> other flavours would anyway.
>
> Fallbacks should be usable on their own. We've generally moved away from 
> having these generic licensed IP compatibles because they always have 
> per platform changes.

Thanks for settling my doubts. I will drop the cdns,qspi-nor then.

Miquèl