linux-kernel - Re: [PATCH v2 3/4] dt-bindings: can: renesas,rcar-canfd: Document RZ/T2H and RZ/N2H SoCs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <124bc6a4-05ee-4682-a0f8-148896eb3c95@kernel.org>
Date: Wed, 7 Jan 2026 09:28:47 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
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>, Biju Das <biju.das.jz@...renesas.com>,
 linux-can@...r.kernel.org, devicetree@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
 Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
 Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH v2 3/4] dt-bindings: can: renesas,rcar-canfd: Document
 RZ/T2H and RZ/N2H SoCs

On 06/01/2026 18:26, Lad, Prabhakar wrote:
> Hi Krzysztof,
> 
> Thank you for the review.
> 
> On Fri, Jan 2, 2026 at 11:20 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>>
>> On Tue, Dec 30, 2025 at 11:58:13AM +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.
>>>
>>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
>>> ---
>>> v1->v2:
>>> - No changes made.
>>> ---
>>>  .../bindings/net/can/renesas,rcar-canfd.yaml  | 26 ++++++++++++++++++-
>>>  1 file changed, 25 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
>>> index fb709cfd26d7..4a83e9e34d67 100644
>>> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
>>> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
>>> @@ -50,6 +50,12 @@ properties:
>>>                - renesas,r9a09g057-canfd     # RZ/V2H(P)
>>>            - const: renesas,r9a09g047-canfd
>>>
>>> +      - const: renesas,r9a09g077-canfd      # RZ/T2H
>>
>>
>> That's part of other enum with single compatibles.
>>
> There is no enum with single compatibles as of in next [0], there is
> only one compatible `renesas,r9a09g047-canfd`. I can club this with
> RZ/T2H one.

This is the one which is supposed to be enum.

> 
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml?h=next-20260106
> 
>>> +
>>> +      - items:
>>> +          - const: renesas,r9a09g087-canfd  # RZ/N2H
>>> +          - const: renesas,r9a09g077-canfd
>>> +
>>>    reg:
>>>      maxItems: 1
>>>
>>> @@ -179,7 +185,6 @@ required:
>>>    - clocks
>>>    - clock-names
>>>    - power-domains
>>> -  - resets
>>>    - assigned-clocks
>>>    - assigned-clock-rates
>>>    - channel0
>>> @@ -243,11 +248,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
>>
>> Why is this de-synced with reset-names? Properties are supposed to
>> behave the same way, not once requiring resets other time requiring
>> reset-names.
>>
> There are SoCs that have a single reset and others that require two
> resets. For SoCs that require two resets, the reset-names property is
> marked as required, while for SoCs with a single reset it is not.

Sure, but I asked why? We expect (and it is documented already in the
docs) that xxx-names always follows xxx, so I really do not understand
why reset-names are valid but resets are not.

> Apart from the RZ/T2H SoC, all SoCs have either one or two resets.
> This difference is why the properties became de-synced. Let me know if
> this can be handled differently.
> 



Best regards,
Krzysztof