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

[sashiko-bot@kernel.org]

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