Re: [PATCH net-next 08/12] dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] In Documentation/devicetree/bindings/net/can/renesas,rcar-
  canfd.yaml, this patch adds `reset-names: false` (line 235) to the…

--

dt-bindings: can: renesas,rcar-canfd: Restrict resets in top-level

This commit moves the broadest constraint for resets (minItems 1,
maxItems 2) to the top level and drops the per-variant maxItems 2. It
also adds reset-names: false for the rcar-gen3-canfd and rcar-gen4-canfd
variants.

Link: https://patch.msgid.link/20261001060825.53335-2-krzysztof.kozlowski@oss.qualcomm.com

> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index bbaaef8f4282e..1a7a9ce45e977 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml

[ ... ]

> @@ -231,6 +232,8 @@ allOf:
>          resets:
>            maxItems: 1
>  
> +        reset-names: false
> +

[Severity: Low]
This isn't a bug, but isn't this rule already in the binding?

Further down in the same allOf list there is a separate block for the
same two compatibles. It already disallows reset-names:

  - if:
      properties:
        compatible:
          contains:
            enum:
              - renesas,rcar-gen3-canfd
              - renesas,rcar-gen4-canfd
    then:
      required:
        - resets
      properties:
        reset-names: false

So the new line duplicates that rule, and validation results for gen3
and gen4 device trees are the same before and after this hunk.

The commit message says:

  Since top-level part says "reset-names" cannot accept one item, disallow
  it for the two variants which do not use it in practice.

That reads as if this patch adds a new restriction. Could the extra line
be dropped, or the two gen3/gen4 blocks be merged into one, and the
commit message updated to match?

>    - if:
>        properties:
>          compatible:

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261110115112.3807247-2-mkl%40pengutronix.de