Hi Geert,
Thanks for the feedback.
-----Original Message----- From: Geert Uytterhoeven geert@linux-m68k.org Sent: 17 November 2025 10:13 Subject: Re: [PATCH] can: rcar_canfd: Fix controller mode setting for RZ/G2L SoCs
Hi Biju,
On Sun, 16 Nov 2025 at 11:31, Biju Das biju.das.jz@bp.renesas.com wrote:
From: Biju Das
Sent: 12 November 2025 08:47 On 30.10.2025 12:05:04, Biju wrote:
The commit 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") applies to all SoCs except the RZ/G2L family of SoCs. As per RZ/G2L hardware manual "Figure 28.16 CAN Setting Procedure after the MCU is Reset" CAN mode needs to be set before channel reset. Add the mode_before_ch_rst variable to struct rcar_canfd_hw_info to handle this difference.
The above commit also breaks CANFD functionality on RZ/G3E. Adapt this change to RZ/G3E, as well as it works ok by following the initialisation sequence of RZ/G2L.
Fixes: 5cff263606a1 ("can: rcar_canfd: Fix controller mode setting") Cc: stable@vger.kernel.org Signed-off-by: Biju Das biju.das.jz@bp.renesas.com
Applied to linux-can.
There are 3 modes for CANFD on RZ/G3E
- CAN-FD mode
- FD only mode
- Classical CAN only mode
In the "FD only mode", the FDOE bit enables the reception and transmission of CAN-FD-only frames. If enabled, communication in the Classical CAN frame format is disabled.
On RZ/G2L, currently, CAN-FD mode is enabled by default and On RZ/G3E and R-Car Gen4, currently FD- only mode is the default.
Prior to commit 5cff263606a1010 ("can: rcar_canfd: Fix controller mode setting) RZ/G3E and R-Car Gen4 are using incorrect code for setting CAN-FD mode. But fortunately, it sets the mode as CAN-FD node, as the channel reset was executed after setting the mode, that resets the registers to CAN-FD mode.(Global reset, set mode, channel reset)
The commit 5cff263606a1010 makes (Global reset, channel reset, set mode), now align with the flow mentioned in the hardware manual for all SoCs except RZ/G2L. But because of the earlier wrong code, it sets to FD-only mode instead of CAN-FD mode.
Is it okay to drop this patch so I can send another patch to make CAN-FD mode as the default for RZ/G3E and R-Car Gen4?
As an enhancement, we need to define a device tree property to support FD-only mode for RZ/G2L, RZ/G3E and R-Car Gen4. Please share your thoughts on this.
Hmm, Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml:
renesas,no-can-fd: $ref: /schemas/types.yaml#/definitions/flag description: The controller can operate in either CAN FD only mode (default) or Classical CAN only mode. The mode is global to all channels. Specify this property to put the controller in Classical CAN only mode.
Maybe we need to remove the "only" word from bindings to avoid confusion. This is coming from R-Car Gen3, which has 2 modes. As per the bit definition of RCMC
0: Classical CAN mode 1: CAN FD mode
As per 48.1.2 Interface Mode od RZ/G2{H,M,N,E} manual RS-CANFD has the following two interface modes.
• Classical CAN mode: Only classical CAN frames are handled. • CAN FD mode: both the classical CAN frames and CAN FD frames are handled.
But RZ/G2L, RZ/G3E and R-Car Gen4, has additional mode called FD-only mode for CAN-FD. In this mode, rx/tx transfer using the canfdtest tool won't work. But cansend/candump works[1].
To summarise, we need the following setting in rcar_canfd_reset_controller():
R-Car Gen3 and RZ/G2L: On Global reset mode set RCMC for CAN-FD or Classical CAN RZ/G2L: On channel reset mode, set FD-only mode or CAN-FD mode. RZ/G3E and R-Car Gen4: On channel reset mode, set CAN-FD mode or FD-only mode or Classical CAN mode
I think there will be 2 patches: 1) Fixes patches to set CAN-FD mode as the default for all SoCs 2) Binding + Driver changes for supporting FD-Only mode for RZ/G2L, R/G3E and R-Car Gen4.
[1] root@smarc-rzg3e:~# candump can1 & [1] 399 root@smarc-rzg3e:~# [ 232.698723] can: controller area network core [ 232.703202] NET: Registered PF_CAN protocol family [ 232.770075] can: raw protocol root@smarc-rzg3e:~# cansend can0 123##0.0011223344556677 can1 123 [08] 00 11 22 33 44 55 66 77 root@smarc-rzg3e:~#
Please share your thoughts.
Cheers, Biju