[PATCH 2/3] can: rockchip: add RK3588 CAN-FD support

[Marc Kleine-Budde]

On 02.07.2026 17:23:59, Cunhao Lu wrote:
> Hi Marc,
>
> > Is the SoC you're using actually a 'v2' silicon revision? At least on
> > the rk3568 the downstream kernel has code to read the revision.
>
> The kernel reports the CAN-FD controller as rk3588v2 rev2.2:
>
>   rockchip_canfd fea60000.can can0: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
>   rockchip_canfd fea70000.can can1: Rockchip-CANFD rk3588v2 rev2.2 (errata 0x0000) found
>
> Following your earlier feedback, I have changed the v2 series to use
> rockchip,rk3588-canfd instead of rockchip,rk3588v2-canfd unless we get
> more information about RK3588 CAN-FD errata and SoC silicon revisions
> from Rockchip.
>
> > Compile the latest https://github.com/linux-can/can-utils/ and test:
> >
> > $ cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32 -b
> > $ cansequence -rv can1 -f
>
> I tested with can0 and can1 directly connected. The CAN clock was
> 200 MHz, and the interfaces were configured as follows:
>
>   ip link set can0 down
>   ip link set can0 type can bitrate 500000 sample-point 0.8 dbitrate 1000000 dsample-point 0.8 fd on
>   ip link set can0 up
>
>   ip link set can1 down
>   ip link set can1 type can bitrate 500000 sample-point 0.8 dbitrate 1000000 dsample-point 0.8 fd on
>   ip link set can1 up
>
> Without BRS, this test ran for 15 minutes without problems:
>
>   cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32
>
> With BRS enabled:
>
>   cangen can0 -I 2 -Li -Di -p 10 -f -g 1 -c32 -b
>
> the test only worked when dbitrate was equal to bitrate, for example
> with both set to 1M. If dbitrate differed from bitrate, the
> controller went bus-off immediately.
>
> So my current conclusion is that CAN-FD itself works on RK3588, but the
> support appears incomplete: using a faster data phase with BRS does not
> work in my setup.

Then CAN-FD is broken. :/

Maybe in a later patch we can hack something, to allow working
configurations.

> This looks different from the issue described by the current
> RKCANFD_QUIRK_CANFD_BROKEN comment. That quirk is about specific
> CAN-FD frames triggering Error Interrupt or Error-Warning during
> reception. In my test the non-BRS CAN-FD frames work, while the failure
> is tied to using BRS with a data bitrate different from the nominal
> bitrate, which immediately drives the controller bus-off.

Can you update the description of the quirk for the rk3588 and add how
to reproduce it?

> Given this result, should I still keep CAN-FD disabled for RK3588, or is
> it acceptable to enable CAN-FD but document that BRS with a faster data
> phase is currently not working?

Please keep it disabled for now.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260702/dce3244a/attachment.sig>