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.
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@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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:
+ - 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
+
- if:
properties:
compatible:
contains:
enum:
+ - renesas,r9a09g077-canfd
- renesas,rcar-gen3-canfd
- renesas,rzg2l-canfd
then:
--
2.52.0On Fri, Jan 09, 2026 at 12:51:27PM +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.
>
> 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@bp.renesas.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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
> + - 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.
The binding was not in a good shape before but you are not improving it.
Best regards,
Krzysztof
Hi Krzysztof,
Thank you for the review.
On Sun, Jan 11, 2026 at 10:14 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Fri, Jan 09, 2026 at 12:51:27PM +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.
> >
> > 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@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.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
On 12/01/2026 15:04, Lad, Prabhakar wrote: > - 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 > Yes, although now I wonder why do you have such case... There are no benefits in disallowing reset-names, even for single entries. Best regards, Krzysztof
Hi Krzysztof,
On Mon, Jan 12, 2026 at 4:30 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 12/01/2026 15:04, Lad, Prabhakar wrote:
> > - 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
> >
>
> Yes, although now I wonder why do you have such case... There are no
> benefits in disallowing reset-names, even for single entries.
>
Ok, I will update the resets property in patch 1/4 as below. Would you
prefer reset-names as a required property for single resets?
reset-names:
minItems: 1
maxItems: 2
items:
enum:
- rstp_n
- rstc_n
Cheers,
Prabhakar
On Mon, 12 Jan 2026 at 18:22, Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> On Mon, Jan 12, 2026 at 4:30 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On 12/01/2026 15:04, Lad, Prabhakar wrote:
> > > - 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
> > >
> >
> > Yes, although now I wonder why do you have such case... There are no
> > benefits in disallowing reset-names, even for single entries.
Except that I have no idea which of the two names I should use in
case of renesas,rcar-gen3-canfd and renesas,rcar-gen4-canfd, as
the hardware documentation doesn't explain that? AFAIU it is just
a single, common reset for the whole block...
> Ok, I will update the resets property in patch 1/4 as below. Would you
> prefer reset-names as a required property for single resets?
>
> reset-names:
> minItems: 1
> maxItems: 2
> items:
> enum:
> - rstp_n
> - rstc_n
I.e. which one should I pick?
<grin>Obviously the first, so dtbs_check succeeds?</grin>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 13/01/2026 20:25, Geert Uytterhoeven wrote: > On Mon, 12 Jan 2026 at 18:22, Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote: >> On Mon, Jan 12, 2026 at 4:30 PM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>> On 12/01/2026 15:04, Lad, Prabhakar wrote: >>>> - 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 >>>> >>> >>> Yes, although now I wonder why do you have such case... There are no >>> benefits in disallowing reset-names, even for single entries. > > Except that I have no idea which of the two names I should use in > case of renesas,rcar-gen3-canfd and renesas,rcar-gen4-canfd, as > the hardware documentation doesn't explain that? AFAIU it is just > a single, common reset for the whole block... So there is a reason why reset-names should be disallowed :). It's fine then. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.