[PATCH v2 0/4] Add CANFD support to R9A09G056/057/077/087 SoCs

[PATCH v2 0/4] Add CANFD support to R9A09G056/057/077/087 SoCs

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Hi All,

This patch series adds CANFD support to RZ/V2H(P), RZ/V2N, RZ/T2H and
RZ/N2H SoCs.
The CANFD controller on RZ/V2H(P) and RZ/V2N SoCs is similar to the one
on RZ/G3E SoC, while the CANFD controller on RZ/T2H and RZ/N2H SoCs is
similar to R-Car Gen 4 SoCs but with some differences in terms of
number of channels and AFLPN and CFTML bits.

The patch series includes:
- Specifying reset-names for RZ/G2L and RZ/G3E CANFD controllers.
- Documenting the CANFD controller on RZ/V2H(P) and RZ/V2N SoCs.
- Documenting the CANFD controller on RZ/T2H and RZ/N2H SoCs.
- Adding RZ/T2H SoC support in the rcar_canfd driver.c file.

Note this patch series applies on top of:
https://lore.kernel.org/all/20251126155911.320563-1-biju.das.jz@bp.renesas.com/

v1->v2:
- Moved reset-names to top-level properties.

Cheers,
Prabhakar

Lad Prabhakar (4):
  dt-bindings: can: renesas,rcar-canfd: Specify reset-names
  dt-bindings: can: renesas,rcar-canfd: Document RZ/V2H(P) and RZ/V2N
    SoCs
  dt-bindings: can: renesas,rcar-canfd: Document RZ/T2H and RZ/N2H SoCs
  can: rcar_canfd: Add RZ/T2H support

 .../bindings/net/can/renesas,rcar-canfd.yaml  | 59 +++++++++++++++----
 drivers/net/can/rcar/rcar_canfd.c             | 18 ++++++
 2 files changed, 65 insertions(+), 12 deletions(-)

-- 
2.52.0

[PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Specify the expected reset-names for the Renesas CAN-FD controller on
RZ/G2L and RZ/G3E SoCs.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- Moved reset-names to top-level properties.
---
 .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index e129bdceef84..9bfd4f44e4d4 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -122,6 +122,11 @@ properties:
 
   resets: true
 
+  reset-names:
+    items:
+      - const: rstp_n
+      - const: rstc_n
+
   renesas,no-can-fd:
     $ref: /schemas/types.yaml#/definitions/flag
     description:
@@ -195,13 +200,6 @@ allOf:
           minItems: 2
           maxItems: 2
 
-        reset-names:
-          minItems: 2
-          maxItems: 2
-
-      required:
-        - reset-names
-
   - if:
       properties:
         compatible:
@@ -239,13 +237,6 @@ allOf:
           minItems: 2
           maxItems: 2
 
-        reset-names:
-          minItems: 2
-          maxItems: 2
-
-      required:
-        - reset-names
-
   - if:
       properties:
         compatible:
@@ -299,6 +290,20 @@ allOf:
       properties:
         renesas,no-can-fd: false
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - renesas,r9a09g047-canfd
+              - renesas,rzg2l-canfd
+    then:
+      required:
+        - reset-names
+    else:
+      properties:
+        reset-names: false
+
 unevaluatedProperties: false
 
 examples:
-- 
2.52.0

Re: [PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Krzysztof Kozlowski]

On Tue, Dec 30, 2025 at 11:58:11AM +0000, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> 
> Specify the expected reset-names for the Renesas CAN-FD controller on
> RZ/G2L and RZ/G3E SoCs.

You should explain here from where you got the actual names.

Otherwise you got following review:

> 
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2:
> - Moved reset-names to top-level properties.
> ---
>  .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
>  1 file changed, 19 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> index e129bdceef84..9bfd4f44e4d4 100644
> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> @@ -122,6 +122,11 @@ properties:
>  
>    resets: true
>  
> +  reset-names:
> +    items:
> +      - const: rstp_n
> +      - const: rstc_n

rst seems redundant. _n as well. Are these names from datasheet? How are
they called in this device (not the soc) datasheet exactly? Because it
feels you use pin or SoC names which is not useful.

Best regards,
Krzysztof

Re: [PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Lad, Prabhakar]

Hi Krzysztof,

Thank you for the review.

On Fri, Jan 2, 2026 at 11:16 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Dec 30, 2025 at 11:58:11AM +0000, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Specify the expected reset-names for the Renesas CAN-FD controller on
> > RZ/G2L and RZ/G3E SoCs.
>
> You should explain here from where you got the actual names.
>
> Otherwise you got following review:
>
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > ---
> > v1->v2:
> > - Moved reset-names to top-level properties.
> > ---
> >  .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
> >  1 file changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > index e129bdceef84..9bfd4f44e4d4 100644
> > --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > @@ -122,6 +122,11 @@ properties:
> >
> >    resets: true
> >
> > +  reset-names:
> > +    items:
> > +      - const: rstp_n
> > +      - const: rstc_n
>
> rst seems redundant. _n as well. Are these names from datasheet? How are
> they called in this device (not the soc) datasheet exactly? Because it
> feels you use pin or SoC names which is not useful.
>
rstp_n/rstc_n are coming from the SoC HW manual and is already used by
the driver (since commit 76e9353a80e9 "can: rcar_canfd: Add support
for RZ/G2L family"). The reset-names existed previously but were
dropped as of commit 466c8ef7b66b "dt-bindings: can:
renesas,rcar-canfd: Simplify the conditional schema". Let me know if
you want me to rename them but the driver will have to maintain the
backward compatibility or do you want me to drop this patch.

Cheers,
Prabhakar

Re: [PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Rob Herring]

On Tue, Jan 06, 2026 at 05:17:17PM +0000, Lad, Prabhakar wrote:
> Hi Krzysztof,
> 
> Thank you for the review.
> 
> On Fri, Jan 2, 2026 at 11:16 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Tue, Dec 30, 2025 at 11:58:11AM +0000, Prabhakar wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > Specify the expected reset-names for the Renesas CAN-FD controller on
> > > RZ/G2L and RZ/G3E SoCs.
> >
> > You should explain here from where you got the actual names.
> >
> > Otherwise you got following review:
> >
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > ---
> > > v1->v2:
> > > - Moved reset-names to top-level properties.
> > > ---
> > >  .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
> > >  1 file changed, 19 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > > index e129bdceef84..9bfd4f44e4d4 100644
> > > --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > > +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > > @@ -122,6 +122,11 @@ properties:
> > >
> > >    resets: true
> > >
> > > +  reset-names:
> > > +    items:
> > > +      - const: rstp_n
> > > +      - const: rstc_n
> >
> > rst seems redundant. _n as well. Are these names from datasheet? How are
> > they called in this device (not the soc) datasheet exactly? Because it
> > feels you use pin or SoC names which is not useful.
> >
> rstp_n/rstc_n are coming from the SoC HW manual and is already used by
> the driver (since commit 76e9353a80e9 "can: rcar_canfd: Add support
> for RZ/G2L family"). The reset-names existed previously but were
> dropped as of commit 466c8ef7b66b "dt-bindings: can:
> renesas,rcar-canfd: Simplify the conditional schema". Let me know if
> you want me to rename them but the driver will have to maintain the
> backward compatibility or do you want me to drop this patch.

The names are fine. The above is useful information that should be in 
the commit msg. Please help us if we've already reviewed something.

Rob

Re: [PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Lad, Prabhakar]

Hi Rob.

On Tue, Jan 6, 2026 at 5:39 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jan 06, 2026 at 05:17:17PM +0000, Lad, Prabhakar wrote:
> > Hi Krzysztof,
> >
> > Thank you for the review.
> >
> > On Fri, Jan 2, 2026 at 11:16 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > On Tue, Dec 30, 2025 at 11:58:11AM +0000, Prabhakar wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > >
> > > > Specify the expected reset-names for the Renesas CAN-FD controller on
> > > > RZ/G2L and RZ/G3E SoCs.
> > >
> > > You should explain here from where you got the actual names.
> > >
> > > Otherwise you got following review:
> > >
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > > ---
> > > > v1->v2:
> > > > - Moved reset-names to top-level properties.
> > > > ---
> > > >  .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
> > > >  1 file changed, 19 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > > > index e129bdceef84..9bfd4f44e4d4 100644
> > > > --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > > > +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> > > > @@ -122,6 +122,11 @@ properties:
> > > >
> > > >    resets: true
> > > >
> > > > +  reset-names:
> > > > +    items:
> > > > +      - const: rstp_n
> > > > +      - const: rstc_n
> > >
> > > rst seems redundant. _n as well. Are these names from datasheet? How are
> > > they called in this device (not the soc) datasheet exactly? Because it
> > > feels you use pin or SoC names which is not useful.
> > >
> > rstp_n/rstc_n are coming from the SoC HW manual and is already used by
> > the driver (since commit 76e9353a80e9 "can: rcar_canfd: Add support
> > for RZ/G2L family"). The reset-names existed previously but were
> > dropped as of commit 466c8ef7b66b "dt-bindings: can:
> > renesas,rcar-canfd: Simplify the conditional schema". Let me know if
> > you want me to rename them but the driver will have to maintain the
> > backward compatibility or do you want me to drop this patch.
>
> The names are fine. The above is useful information that should be in
> the commit msg. Please help us if we've already reviewed something.
>
Sure, I'll add the above info in the commit message and re-spin the series.

Cheers,
Prabhakar

Re: [PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Krzysztof Kozlowski]

On 06/01/2026 18:17, Lad, Prabhakar wrote:
> Hi Krzysztof,
> 
> Thank you for the review.
> 
> On Fri, Jan 2, 2026 at 11:16 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Tue, Dec 30, 2025 at 11:58:11AM +0000, Prabhakar wrote:
>>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>>>
>>> Specify the expected reset-names for the Renesas CAN-FD controller on
>>> RZ/G2L and RZ/G3E SoCs.
>>
>> You should explain here from where you got the actual names.
>>
>> Otherwise you got following review:
>>
>>>
>>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>>> ---
>>> v1->v2:
>>> - Moved reset-names to top-level properties.
>>> ---
>>>  .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
>>>  1 file changed, 19 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
>>> index e129bdceef84..9bfd4f44e4d4 100644
>>> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
>>> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
>>> @@ -122,6 +122,11 @@ properties:
>>>
>>>    resets: true
>>>
>>> +  reset-names:
>>> +    items:
>>> +      - const: rstp_n
>>> +      - const: rstc_n
>>
>> rst seems redundant. _n as well. Are these names from datasheet? How are
>> they called in this device (not the soc) datasheet exactly? Because it
>> feels you use pin or SoC names which is not useful.
>>
> rstp_n/rstc_n are coming from the SoC HW manual and is already used by
> the driver (since commit 76e9353a80e9 "can: rcar_canfd: Add support
> for RZ/G2L family"). The reset-names existed previously but were
> dropped as of commit 466c8ef7b66b "dt-bindings: can:
> renesas,rcar-canfd: Simplify the conditional schema". Let me know if
> you want me to rename them but the driver will have to maintain the

No, I want to follow my first comment in my reply.

Best regards,
Krzysztof

Re: [PATCH v2 1/4] dt-bindings: can: renesas,rcar-canfd: Specify reset-names

[Lad, Prabhakar]

Hi Krzysztof,

On Wed, Jan 7, 2026 at 8:25 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 06/01/2026 18:17, Lad, Prabhakar wrote:
> > Hi Krzysztof,
> >
> > Thank you for the review.
> >
> > On Fri, Jan 2, 2026 at 11:16 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On Tue, Dec 30, 2025 at 11:58:11AM +0000, Prabhakar wrote:
> >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >>>
> >>> Specify the expected reset-names for the Renesas CAN-FD controller on
> >>> RZ/G2L and RZ/G3E SoCs.
> >>
> >> You should explain here from where you got the actual names.
> >>
> >> Otherwise you got following review:
> >>
> >>>
> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >>> ---
> >>> v1->v2:
> >>> - Moved reset-names to top-level properties.
> >>> ---
> >>>  .../bindings/net/can/renesas,rcar-canfd.yaml  | 33 +++++++++++--------
> >>>  1 file changed, 19 insertions(+), 14 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> >>> index e129bdceef84..9bfd4f44e4d4 100644
> >>> --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> >>> +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
> >>> @@ -122,6 +122,11 @@ properties:
> >>>
> >>>    resets: true
> >>>
> >>> +  reset-names:
> >>> +    items:
> >>> +      - const: rstp_n
> >>> +      - const: rstc_n
> >>
> >> rst seems redundant. _n as well. Are these names from datasheet? How are
> >> they called in this device (not the soc) datasheet exactly? Because it
> >> feels you use pin or SoC names which is not useful.
> >>
> > rstp_n/rstc_n are coming from the SoC HW manual and is already used by
> > the driver (since commit 76e9353a80e9 "can: rcar_canfd: Add support
> > for RZ/G2L family"). The reset-names existed previously but were
> > dropped as of commit 466c8ef7b66b "dt-bindings: can:
> > renesas,rcar-canfd: Simplify the conditional schema". Let me know if
> > you want me to rename them but the driver will have to maintain the
>
> No, I want to follow my first comment in my reply.
>
Ok. As replied to Rob earlier I'll include the below info in the commit message:

The reset names rstp_n and rstc_n are defined in the SoC hardware
manual and are already used by the driver (since commit 76e9353a80e9
"can: rcar_canfd: Add support for RZ/G2L family"). The reset-names
property existed previously but was dropped in commit 466c8ef7b66b
"dt-bindings: can: renesas,rcar-canfd: Simplify the conditional
schema".

Cheers,
Prabhakar

[PATCH v2 2/4] dt-bindings: can: renesas,rcar-canfd: Document RZ/V2H(P) and RZ/V2N SoCs

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Document CANFD IP found on the Renesas RZ/V2H(P) (R9A09G057) and RZ/V2N
(R9A09G056) SoCs. The CANFD IP on these SoCs are identical to that found
on the RZ/G3E (R9A09G047) SoC.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- No changes made.
---
 .../devicetree/bindings/net/can/renesas,rcar-canfd.yaml     | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
index 9bfd4f44e4d4..fb709cfd26d7 100644
--- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
@@ -44,6 +44,12 @@ properties:
 
       - const: renesas,r9a09g047-canfd     # RZ/G3E
 
+      - items:
+          - enum:
+              - renesas,r9a09g056-canfd     # RZ/V2N
+              - renesas,r9a09g057-canfd     # RZ/V2H(P)
+          - const: renesas,r9a09g047-canfd
+
   reg:
     maxItems: 1
 
-- 
2.52.0

Re: [PATCH v2 2/4] dt-bindings: can: renesas,rcar-canfd: Document RZ/V2H(P) and RZ/V2N SoCs

[Krzysztof Kozlowski]

On Tue, Dec 30, 2025 at 11:58:12AM +0000, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> 
> Document CANFD IP found on the Renesas RZ/V2H(P) (R9A09G057) and RZ/V2N
> (R9A09G056) SoCs. The CANFD IP on these SoCs are identical to that found
> on the RZ/G3E (R9A09G047) SoC.
> 
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 2/4] dt-bindings: can: renesas,rcar-canfd: Document RZ/V2H(P) and RZ/V2N SoCs

[Geert Uytterhoeven]

On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Document CANFD IP found on the Renesas RZ/V2H(P) (R9A09G057) and RZ/V2N
> (R9A09G056) SoCs. The CANFD IP on these SoCs are identical to that found
> on the RZ/G3E (R9A09G047) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

After downloading RZ/V2H Hardware User Manual Rev.1.30, and noticing
CFDCnNCFG.NSJW = 0 is no longer prohibited:

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

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

[Prabhakar]

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
+
+      - 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
+
   - if:
       properties:
         compatible:
           contains:
             enum:
+              - renesas,r9a09g077-canfd
               - renesas,rcar-gen3-canfd
               - renesas,rzg2l-canfd
     then:
-- 
2.52.0

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

[Krzysztof Kozlowski]

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.

> +
> +      - 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.

Best regards,
Krzysztof

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

[Lad, Prabhakar]

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.

[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.
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.

Cheers,
Prabhakar

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

[Krzysztof Kozlowski]

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

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

[Lad, Prabhakar]

Hi Krzysztof,

On Wed, Jan 7, 2026 at 8:28 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> 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.
>
Ok.

> >
> > [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.
>
Sorry for being clear earlier, it's already taken care in patch 1/4
[1] with the below hunk which will restrict RZ/T2H to not allow
reset-names.

+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - renesas,r9a09g047-canfd
+              - renesas,rzg2l-canfd
+    then:
+      required:
+        - reset-names
+    else:
+      properties:
+        reset-names: false


[1] https://lore.kernel.org/all/20251230115814.53536-2-prabhakar.mahadev-lad.rj@bp.renesas.com/

Cheers,
Prabhakar

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

[Geert Uytterhoeven]

On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> 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>

For the content:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

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

[PATCH v2 4/4] can: rcar_canfd: Add RZ/T2H support

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

The CAN-FD IP on the RZ/T2H SoC is similar to R-Car Gen4, but differs in
the AFLPN and CFTML bits and supports two channels with eight interrupts.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- No changes made.
---
 drivers/net/can/rcar/rcar_canfd.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c
index 4a653d8978ba..eaf8cac78038 100644
--- a/drivers/net/can/rcar/rcar_canfd.c
+++ b/drivers/net/can/rcar/rcar_canfd.c
@@ -670,6 +670,23 @@ static const struct rcar_canfd_hw_info r9a09g047_hw_info = {
 	.external_clk = 0,
 };
 
+static const struct rcar_canfd_hw_info r9a09g077_hw_info = {
+	.nom_bittiming = &rcar_canfd_gen4_nom_bittiming_const,
+	.data_bittiming = &rcar_canfd_gen4_data_bittiming_const,
+	.tdc_const = &rcar_canfd_gen4_tdc_const,
+	.regs = &rcar_gen4_regs,
+	.sh = &rcar_gen4_shift_data,
+	.rnc_field_width = 16,
+	.max_aflpn = 15,
+	.max_cftml = 31,
+	.max_channels = 2,
+	.postdiv = 1,
+	.multi_channel_irqs = 1,
+	.ch_interface_mode = 1,
+	.shared_can_regs = 1,
+	.external_clk = 1,
+};
+
 /* Helper functions */
 static inline void rcar_canfd_update(u32 mask, u32 val, u32 __iomem *reg)
 {
@@ -2345,6 +2362,7 @@ static DEFINE_SIMPLE_DEV_PM_OPS(rcar_canfd_pm_ops, rcar_canfd_suspend,
 static const __maybe_unused struct of_device_id rcar_canfd_of_table[] = {
 	{ .compatible = "renesas,r8a779a0-canfd", .data = &rcar_gen4_hw_info },
 	{ .compatible = "renesas,r9a09g047-canfd", .data = &r9a09g047_hw_info },
+	{ .compatible = "renesas,r9a09g077-canfd", .data = &r9a09g077_hw_info },
 	{ .compatible = "renesas,rcar-gen3-canfd", .data = &rcar_gen3_hw_info },
 	{ .compatible = "renesas,rcar-gen4-canfd", .data = &rcar_gen4_hw_info },
 	{ .compatible = "renesas,rzg2l-canfd", .data = &rzg2l_hw_info },
-- 
2.52.0

Re: [PATCH v2 4/4] can: rcar_canfd: Add RZ/T2H support

[Geert Uytterhoeven]

Hi Prabhakar,

On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The CAN-FD IP on the RZ/T2H SoC is similar to R-Car Gen4, but differs in
> the AFLPN and CFTML bits and supports two channels with eight interrupts.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Thanks for your patch!

LGTM, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

However, compared to other SoCs, CFDCnNCFG.NSJW[6:0] has:

    0x00: Setting prohibited

Perhaps this is a documentation issue, as the same limitation was
dropped in RZ/V2H Hardware User Manual Rev.1.30?
Linux also has no can_bittiming_const.sjw_min field.

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

Re: [PATCH v2 4/4] can: rcar_canfd: Add RZ/T2H support

[Lad, Prabhakar]

Hi Geert,

Thank you for the review.

On Wed, Jan 7, 2026 at 4:37 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > The CAN-FD IP on the RZ/T2H SoC is similar to R-Car Gen4, but differs in
> > the AFLPN and CFTML bits and supports two channels with eight interrupts.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Thanks for your patch!
>
> LGTM, so
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> However, compared to other SoCs, CFDCnNCFG.NSJW[6:0] has:
>
>     0x00: Setting prohibited
>
Sharp eye!

> Perhaps this is a documentation issue, as the same limitation was
> dropped in RZ/V2H Hardware User Manual Rev.1.30?
> Linux also has no can_bittiming_const.sjw_min field.
>
I've notified the HW team to get it clarified.

Cheers,
Prabhakar

> 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

Re: [PATCH v2 4/4] can: rcar_canfd: Add RZ/T2H support

[Geert Uytterhoeven]

Hi Prabhakar,

On Thu, 8 Jan 2026 at 11:13, Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> On Wed, Jan 7, 2026 at 4:37 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > The CAN-FD IP on the RZ/T2H SoC is similar to R-Car Gen4, but differs in
> > > the AFLPN and CFTML bits and supports two channels with eight interrupts.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Thanks for your patch!
> >
> > LGTM, so
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > However, compared to other SoCs, CFDCnNCFG.NSJW[6:0] has:
> >
> >     0x00: Setting prohibited
> >
> Sharp eye!

I knew what I had to look for ;-)

This one was indeed hard to compare with other SoCs, as the structure
is completely different. For e.g. RZ/V2H and RZ/G3E, I could just use
diffpdf, restricted to the pages I am interested in.

Still need to enhance diffpdf with shift up/down buttons, so I don't
have to adjust the page numbers manually when a few lines are suddenly
moved to a new page...

> > Perhaps this is a documentation issue, as the same limitation was
> > dropped in RZ/V2H Hardware User Manual Rev.1.30?
> > Linux also has no can_bittiming_const.sjw_min field.
> >
> I've notified the HW team to get it clarified.

Thanks!

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

Re: [PATCH v2 4/4] can: rcar_canfd: Add RZ/T2H support

[Lad, Prabhakar]

Hi Geert,

On Thu, Jan 8, 2026 at 10:21 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Thu, 8 Jan 2026 at 11:13, Lad, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > On Wed, Jan 7, 2026 at 4:37 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > >
> > > > The CAN-FD IP on the RZ/T2H SoC is similar to R-Car Gen4, but differs in
> > > > the AFLPN and CFTML bits and supports two channels with eight interrupts.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > Thanks for your patch!
> > >
> > > LGTM, so
> > > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > >
> > > However, compared to other SoCs, CFDCnNCFG.NSJW[6:0] has:
> > >
> > >     0x00: Setting prohibited
> > >
> > Sharp eye!
>
> I knew what I had to look for ;-)
>
;-)

> This one was indeed hard to compare with other SoCs, as the structure
> is completely different. For e.g. RZ/V2H and RZ/G3E, I could just use
> diffpdf, restricted to the pages I am interested in.
>
Yes, the T2H manual is different as compared to G3E/V2H.

> Still need to enhance diffpdf with shift up/down buttons, so I don't
> have to adjust the page numbers manually when a few lines are suddenly
> moved to a new page...
diffpdf was insightful, I wasn't aware such a tool existed this will
be quite handy. Thank you for the pointer.

Cheers,
Prabhakar

Re: [PATCH v2 4/4] can: rcar_canfd: Add RZ/T2H support

[Lad, Prabhakar]

Hi Geert,

On Wed, Jan 7, 2026 at 4:37 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Tue, 30 Dec 2025 at 12:58, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > The CAN-FD IP on the RZ/T2H SoC is similar to R-Car Gen4, but differs in
> > the AFLPN and CFTML bits and supports two channels with eight interrupts.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Thanks for your patch!
>
> LGTM, so
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> However, compared to other SoCs, CFDCnNCFG.NSJW[6:0] has:
>
>     0x00: Setting prohibited
>
> Perhaps this is a documentation issue, as the same limitation was
> dropped in RZ/V2H Hardware User Manual Rev.1.30?
>
I got confirmation from the HW team that it's a typo. Similar to
RZ/V2H, setting it to 0x00 results in 1 Tq and this shall be reflected
in the next UM update.

Cheers,
Prabhakar