Message-ID: <CA+V-a8un48Gfqg-K6YToxUgnZawOcb-nQHsBcOfHdpAR7_Uu4Q@mail.gmail.com>
Date: Mon, 12 Jan 2026 14:04:28 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>, Vincent Mailhol <mailhol@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Geert Uytterhoeven <geert+renesas@...der.be>, Magnus Damm <magnus.damm@...il.com>, 
	linux-can@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v3 3/4] dt-bindings: can: renesas,rcar-canfd: Document
 RZ/T2H and RZ/N2H SoCs

Hi Krzysztof,

Thank you for the review.

On Sun, Jan 11, 2026 at 10:14 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On Fri, Jan 09, 2026 at 12:51:27PM +0000, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> >
> > Document the CAN-FD controller used on the RZ/T2H and RZ/N2H SoCs. The
> > CAN-FD IP is largely compatible with the R-Car Gen4 block, but differs
> > in that AFLPN and CFTML are different, there is no reset line for the IP,
> > and it only supports two channels.
> >
> > The schema already enforces reset-names only for RZ/G2L and RZ/G3E and
> > disallows it for all other SoCs, so only the resets property is explicitly
> > marked as unsupported for RZ/T2H and RZ/N2H.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> > ---
> > v2->v3:
> > - Grouped single compatible entries into an enum.
> > - Updated commit message about disallowing reset-names property.
> > - Added Reviewed-by tag.
> >
> > v1->v2:
> > - No changes made.
> > ---
> >  .../bindings/net/can/renesas,rcar-canfd.yaml  | 29 +++++++++++++++++--
> >  1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > index fb709cfd26d7..ceb072e0a304 100644
> > --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > @@ -42,7 +42,10 @@ properties:
> >                - renesas,r9a07g054-canfd    # RZ/V2L
> >            - const: renesas,rzg2l-canfd     # RZ/G2L family
> >
> > -      - const: renesas,r9a09g047-canfd     # RZ/G3E
> > +      - items:
>
> The convention is enum and that's what I asked. I know it is a nit, but
> if I give review now for this code which I disagreed, my disagreement
> won't be ever recorded and people in future work will base on this less
> preferred syntax.
>
> So again:
>
> - enum:
>     - foo
>     - bar
>
Agreed, I will drop the "-items" and I will also move the single
compatible list entry to the top based on the feedback [0].

[0] https://lore.kernel.org/all/CAMuHMdWz6_NzvjZNMLk+Bqoa0NR2CKNFwDXynfmrTZgOGsqxTA@mail.gmail.com/

> > +          - enum:
> > +              - renesas,r9a09g047-canfd    # RZ/G3E
> > +              - renesas,r9a09g077-canfd    # RZ/T2H
> >
> >        - items:
> >            - enum:
> > @@ -50,6 +53,10 @@ properties:
> >                - renesas,r9a09g057-canfd     # RZ/V2H(P)
> >            - const: renesas,r9a09g047-canfd
> >
> > +      - items:
> > +          - const: renesas,r9a09g087-canfd  # RZ/N2H
> > +          - const: renesas,r9a09g077-canfd
> > +
> >    reg:
> >      maxItems: 1
> >
> > @@ -179,7 +186,6 @@ required:
> >    - clocks
> >    - clock-names
> >    - power-domains
> > -  - resets
> >    - assigned-clocks
> >    - assigned-clock-rates
> >    - channel0
> > @@ -243,11 +249,30 @@ allOf:
> >            minItems: 2
> >            maxItems: 2
> >
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            const: renesas,r9a09g077-canfd
> > +    then:
> > +      properties:
> > +        interrupts:
> > +          maxItems: 8
> > +
> > +        interrupt-names:
> > +          maxItems: 8
> > +
> > +        resets: false
> > +    else:
> > +      required:
> > +        - resets
>
> I do not think you are making this binding easy to maintain. You have
> now multiple separate ifs AND two ifs with "else:" condition. Try to
> understand which condition/description applies to "rcar-gen3". Does it
> require resets? Let's look for the compatible in the file - you find
> "if:" block requiring reset-names but no "require" for resets. Odd.
>
> As I said last time, these should be alwaysy synced.
>
Does the below look OK? Ive grouped them based on no rests/single
reset/ two reset.

  - if:
      properties:
        compatible:
          contains:
            # SoCs WITHOUT resets
            const: renesas,r9a09g077-canfd
    then:
      properties:
        resets: false
        reset-names: false

  - if:
      properties:
        compatible:
          contains:
            # SoCs WITH resets and reset-names
            enum:
              - renesas,r9a09g047-canfd
              - renesas,rzg2l-canfd
    then:
      required:
        - resets
        - reset-names

  - if:
      properties:
        compatible:
          contains:
            # SoCs WITH resets but WITHOUT reset-names
            enum:
              - renesas,rcar-gen3-canfd
              - renesas,rcar-gen4-canfd
    then:
      required:
        - resets
      properties:
        reset-names: false

Cheers,
Prabhakar

Powered by blists - more mailing lists