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

[Krzysztof Kozlowski <krzk@kernel.org>]

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@kernel.org> wrote:
>>
>> On Tue, Dec 30, 2025 at 11:58:13AM +0000, Prabhakar wrote:
>>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.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@bp.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