[PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible

[PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible

[1579567540]

From: luch00 <1579567540@qq.com>

The RK3588 CAN-FD controller uses the same DT properties as the
existing Rockchip CAN-FD blocks, so extend the current schema with a
SoC-specific rockchip,rk3588v2-canfd compatible instead of creating a
new binding file.

Keep RK3588v2 as its own compatible rather than an rk3568v2 fallback.
Driver support uses separate match data and the RX FIFO count field
layout differs from rk3568v2, so a dedicated compatible is the safer
description.

Signed-off-by: luch00 <1579567540@qq.com>
---
 .../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml     | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c0330..aa31ec78e 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -17,6 +17,7 @@ properties:
   compatible:
     oneOf:
       - const: rockchip,rk3568v2-canfd
+      - const: rockchip,rk3588v2-canfd
       - items:
           - const: rockchip,rk3568v3-canfd
           - const: rockchip,rk3568v2-canfd
-- 
2.34.1

Re: [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible

[Krzysztof Kozlowski]

On Wed, Jul 01, 2026 at 03:01:26PM +0800, 1579567540@qq.com wrote:
> From: luch00 <1579567540@qq.com>
> 
> The RK3588 CAN-FD controller uses the same DT properties as the
> existing Rockchip CAN-FD blocks, so extend the current schema with a

DT properties have nothing to do here. Are you saying it is fully
compatible? Then express it properly with fallback.

> SoC-specific rockchip,rk3588v2-canfd compatible instead of creating a
> new binding file.
> 
> Keep RK3588v2 as its own compatible rather than an rk3568v2 fallback.

Do not explain what you did. Explain WHY.

> Driver support uses separate match data and the RX FIFO count field

Driver is irrelevant here.

> layout differs from rk3568v2, so a dedicated compatible is the safer
> description.
> 
> Signed-off-by: luch00 <1579567540@qq.com>

We do not take anonymous contributions.

> ---
>  .../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml     | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> index a077c0330..aa31ec78e 100644
> --- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> +++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
> @@ -17,6 +17,7 @@ properties:
>    compatible:
>      oneOf:
>        - const: rockchip,rk3568v2-canfd
> +      - const: rockchip,rk3588v2-canfd

So that's just enum with previous entry

And why is this different from rk3588?


>        - items:
>            - const: rockchip,rk3568v3-canfd
>            - const: rockchip,rk3568v2-canfd
> -- 
> 2.34.1
> 

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

[1579567540]

From: luch00 <1579567540@qq.com>

Add support for the RK3588v2 CAN-FD controller by introducing a
dedicated model ID and OF match entry.

The block is closely related to the existing RK3568 variants, but it
cannot reuse their match data unchanged. In particular, RK3588v2
encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
SoC-specific handling.

Validation on RK3588v2 also shows that its observed errata profile does
not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
variant instead of relying on an rk3568 fallback.

Signed-off-by: luch00 <1579567540@qq.com>
---
 drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
 drivers/net/can/rockchip/rockchip_canfd-rx.c   |  5 ++++-
 drivers/net/can/rockchip/rockchip_canfd.h      | 12 +++++++++++-
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e..3c2480785 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
 		RKCANFD_QUIRK_CANFD_BROKEN,
 };
 
+/* Tests on the rk3588v2 reproduce Erratum 5, but not
+ * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
+ * on rk3568v2/rk3568v3.
+ */
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588v2 = {
+	.model = RKCANFD_MODEL_RK3588V2,
+	.quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5,
+};
+
 static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
 {
 	switch (model) {
@@ -57,6 +66,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
 		return "rk3568v2";
 	case RKCANFD_MODEL_RK3568V3:
 		return "rk3568v3";
+	case RKCANFD_MODEL_RK3588V2:
+		return "rk3588v2";
 	}
 
 	return "<unknown>";
@@ -846,6 +857,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
 	}, {
 		.compatible = "rockchip,rk3568v3-canfd",
 		.data = &rkcanfd_devtype_data_rk3568v3,
+	}, {
+		.compatible = "rockchip,rk3588v2-canfd",
+		.data = &rkcanfd_devtype_data_rk3588v2,
 	}, {
 		/* sentinel */
 	},
diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
index 475c0409e..fe64db373 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
 {
 	const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
 
-	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
+	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
+		return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
+
+	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
 }
 
 int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7..f6105b904 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -214,7 +214,8 @@
 #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
 
 #define RKCANFD_REG_RX_FIFO_CTRL 0x118
-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
 #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)
 #define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)
 
@@ -331,6 +332,11 @@
  * rarely with the standard clock of 300 MHz, but almost immediately
  * at 80 MHz.
  *
+ * Test on the rk3588v2 shows the same empty FIFO condition.
+ * In that setup rx_fifo_empty_errors increments when the bus
+ * transitions from idle to high CAN-FD load and stops growing once
+ * the bus reaches a steady state.
+ *
  * To workaround this problem, check for empty FIFO with
  * rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit
  * early.
@@ -424,6 +430,9 @@
  *     cansequence -rv -i 1
  *
  * - TX starvation after repeated Bus-Off
+ *   Tests on the rk3588v2 show the same problem. In a
+ *   10-cycle Bus-Off recovery test, 9 cycles failed to send after the
+ *   controller restarted.
  *   To reproduce:
  *   host:
  *     sleep 3 && cangen can0 -I2 -Li -Di -p10 -g 0.0
@@ -434,6 +443,7 @@
 enum rkcanfd_model {
 	RKCANFD_MODEL_RK3568V2 = 0x35682,
 	RKCANFD_MODEL_RK3568V3 = 0x35683,
+	RKCANFD_MODEL_RK3588V2 = 0x35882,
 };
 
 struct rkcanfd_devtype_data {
-- 
2.34.1

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

[Heiko Stübner]

Hi,

Am Mittwoch, 1. Juli 2026, 09:01:27 Mitteleuropäische Sommerzeit schrieb 1579567540@qq.com:
> From: luch00 <1579567540@qq.com>

please use a real name, not an alias.


> Add support for the RK3588v2 CAN-FD controller by introducing a
> dedicated model ID and OF match entry.
> 
> The block is closely related to the existing RK3568 variants, but it
> cannot reuse their match data unchanged. In particular, RK3588v2
> encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
> SoC-specific handling.
> 
> Validation on RK3588v2 also shows that its observed errata profile does
> not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
> variant instead of relying on an rk3568 fallback.

Funnily enough, we seem to have worked on the same topic
at the same time :-)

https://lore.kernel.org/lkml/20260630164336.3444550-1-heiko@sntech.de/

> Signed-off-by: luch00 <1579567540@qq.com>
> ---
>  drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
>  drivers/net/can/rockchip/rockchip_canfd-rx.c   |  5 ++++-
>  drivers/net/can/rockchip/rockchip_canfd.h      | 12 +++++++++++-
>  3 files changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
> index 29de0c01e..3c2480785 100644
> --- a/drivers/net/can/rockchip/rockchip_canfd-core.c
> +++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
> @@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
>  		RKCANFD_QUIRK_CANFD_BROKEN,
>  };
>  
> +/* Tests on the rk3588v2 reproduce Erratum 5, but not
> + * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
> + * on rk3568v2/rk3568v3.
> + */

Here I could reproduce erratum 6 though:
https://lore.kernel.org/lkml/20260630164336.3444550-4-heiko@sntech.de/


[...]

> diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> index 475c0409e..fe64db373 100644
> --- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
> +++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> @@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
>  {
>  	const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
>  
> -	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
> +	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
> +		return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
> +
> +	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
>  }
>  
>  int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
> diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
> index 93131c7d7..f6105b904 100644
> --- a/drivers/net/can/rockchip/rockchip_canfd.h
> +++ b/drivers/net/can/rockchip/rockchip_canfd.h
> @@ -214,7 +214,8 @@
>  #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
>  
>  #define RKCANFD_REG_RX_FIFO_CTRL 0x118
> -#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
> +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
> +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)

Oh, didn't see this when doing my variant of the support, so cool that you
found this.


Heiko

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

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]

On 01.07.2026 11:55:39, Heiko Stübner wrote:
> Hi,
>
> Am Mittwoch, 1. Juli 2026, 09:01:27 Mitteleuropäische Sommerzeit schrieb 1579567540@qq.com:
> > From: luch00 <1579567540@qq.com>
>
> please use a real name, not an alias.
>
>
> > Add support for the RK3588v2 CAN-FD controller by introducing a
> > dedicated model ID and OF match entry.
> >
> > The block is closely related to the existing RK3568 variants, but it
> > cannot reuse their match data unchanged. In particular, RK3588v2
> > encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
> > SoC-specific handling.
> >
> > Validation on RK3588v2 also shows that its observed errata profile does
> > not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
> > variant instead of relying on an rk3568 fallback.
>
> Funnily enough, we seem to have worked on the same topic
> at the same time :-)
>
> https://lore.kernel.org/lkml/20260630164336.3444550-1-heiko@sntech.de/
>
> > Signed-off-by: luch00 <1579567540@qq.com>
> > ---
> >  drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
> >  drivers/net/can/rockchip/rockchip_canfd-rx.c   |  5 ++++-
> >  drivers/net/can/rockchip/rockchip_canfd.h      | 12 +++++++++++-
> >  3 files changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
> > index 29de0c01e..3c2480785 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd-core.c
> > +++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
> > @@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
> >  		RKCANFD_QUIRK_CANFD_BROKEN,
> >  };
> >
> > +/* Tests on the rk3588v2 reproduce Erratum 5, but not
> > + * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
> > + * on rk3568v2/rk3568v3.
> > + */
>
> Here I could reproduce erratum 6 though:
> https://lore.kernel.org/lkml/20260630164336.3444550-4-heiko@sntech.de/
>
>
> [...]
>
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > index 475c0409e..fe64db373 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > +++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
> > @@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
> >  {
> >  	const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
> >
> > -	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
> > +	if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
> > +		return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
> > +
> > +	return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
> >  }
> >
> >  int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
> > diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
> > index 93131c7d7..f6105b904 100644
> > --- a/drivers/net/can/rockchip/rockchip_canfd.h
> > +++ b/drivers/net/can/rockchip/rockchip_canfd.h
> > @@ -214,7 +214,8 @@
> >  #define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
> >
> >  #define RKCANFD_REG_RX_FIFO_CTRL 0x118
> > -#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
> > +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
> > +#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
>
> Oh, didn't see this when doing my variant of the support, so cool that you
> found this.

The "Rockchip RK3588 TRM V1.0-Part1-20220309.pdf" datasheet says bits
"7:5" are RX_FIFO_FRAME_CNT, while bit "6" is marked as reserved. 🤷

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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[💫.220]

Hi Heiko, Marc,

thanks for the review.

> please use a real name, not an alias.

I will use my real name in future revisions.

> Funnily enough, we seem to have worked on the same topic
> at the same time :-)
>
> https://lore.kernel.org/lkml/20260630164336.3444550-1-heiko@sntech.de/

I missed Heiko's series before sending mine, sorry for the noise.
(But it really is a very interesting coincidence.)
Since the series overlap, I am happy to base further work on Heiko's
series, or to let Heiko fold the RK3588 RX_FIFO_CNT bitfield change into
his v2 if that is preferred.

> Here I could reproduce erratum 6 though:
> https://lore.kernel.org/lkml/20260630164336.3444550-4-heiko@sntech.de/

Thanks for pointing this out. My local test setup did not reproduce it,
but given Heiko's result I agree that RK3588v2 should keep the erratum 6
workaround enabled. If I respin this series, I will remove the "not
reproduced" statement and enable RKCANFD_QUIRK_RK3568_ERRATUM_6 for
RK3588v2.

> The "Rockchip RK3588 TRM V1.0-Part1-20220309.pdf" datasheet says bits
> "7:5" are RX_FIFO_FRAME_CNT, while bit "6" is marked as reserved.

For RX_FIFO_CNT, I found the bitfield difference by reading Rockchip's
vendor kernel 6.1 driver and comparing the CAN support for RK3568 and
RK3588. The vendor driver uses different RX FIFO count bitfields for the
two SoCs, and my testing on RK3588v2 also indicates that bits 7:5 are
needed. I can add a short note about this in the commit message or
code comment.

One more question about RKCANFD_QUIRK_CANFD_BROKEN: in my RK3588v2 test
setup the two known CAN-FD trigger frames did not cause an Error
Interrupt or Error-Warning. I also ran a 12 hour CAN-FD stress test with
can0/can1 directly connected, 200 MHz CAN clock, 500 kbit/s nominal
bitrate and 1 Mbit/s data bitrate. That test included periodic
transmission of the two CANFD_BROKEN frames, variable DLC CAN-FD frames,
CAN-FD+BRS+EFF load, and a canfdtest run with 19,417,129 frames without
data mismatch.

Would it make sense to leave RKCANFD_QUIRK_CANFD_BROKEN disabled for
RK3588v2, or have you seen this issue on RK3588 as well?

Thanks,
Cunhao Lu

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

[Heiko Stübner]

Am Mittwoch, 1. Juli 2026, 14:29:22 Mitteleuropäische Sommerzeit schrieb 💫.220:
> Hi Heiko, Marc,
> 
> thanks for the review.
> 
> > please use a real name, not an alias.
> 
> I will use my real name in future revisions.
> 
> > Funnily enough, we seem to have worked on the same topic
> > at the same time :-)
> >
> > https://lore.kernel.org/lkml/20260630164336.3444550-1-heiko@sntech.de/
> 
> I missed Heiko's series before sending mine, sorry for the noise.
> (But it really is a very interesting coincidence.)
> Since the series overlap, I am happy to base further work on Heiko's
> series, or to let Heiko fold the RK3588 RX_FIFO_CNT bitfield change into
> his v2 if that is preferred.

I don't think we need two people working on this and you did the better
investigation into the differences, so you should get the credit :-)

So I guess my preference would be to:
- pick up the erratum 6 into your patch
- add my haikou patch to the series - that way we also get a user
- handle Krzysztof's comment from
  https://lore.kernel.org/linux-rockchip/20260701-sensible-cryptic-ocelot-58035b@quoll/

  as both our bindings have the same structure, so I guess it should be

    oneOf:
       - enum:
             rockchip,rk3568v2-canfd
             rockchip,rk3588v2-canfd
       - items:
           - const: rockchip,rk3568v3-canfd
           - const: rockchip,rk3568v2-canfd

And submit that as v2.


> For RX_FIFO_CNT, I found the bitfield difference by reading Rockchip's
> vendor kernel 6.1 driver and comparing the CAN support for RK3568 and
> RK3588. The vendor driver uses different RX FIFO count bitfields for the
> two SoCs, and my testing on RK3588v2 also indicates that bits 7:5 are
> needed. I can add a short note about this in the commit message or
> code comment.

It's already in the commit message, so that should be fine


> One more question about RKCANFD_QUIRK_CANFD_BROKEN: in my RK3588v2 test
> setup the two known CAN-FD trigger frames did not cause an Error
> Interrupt or Error-Warning. I also ran a 12 hour CAN-FD stress test with
> can0/can1 directly connected, 200 MHz CAN clock, 500 kbit/s nominal
> bitrate and 1 Mbit/s data bitrate. That test included periodic
> transmission of the two CANFD_BROKEN frames, variable DLC CAN-FD frames,
> CAN-FD+BRS+EFF load, and a canfdtest run with 19,417,129 frames without
> data mismatch.
> 
> Would it make sense to leave RKCANFD_QUIRK_CANFD_BROKEN disabled for
> RK3588v2, or have you seen this issue on RK3588 as well?

I was more going by the fact that even Rockchip removed every mention of
the -FD from all documentation, so was assuming it still being broken as
before. But if it actually works, then personally I'm more than fine with
enabling CAN-FD :-D .

I guess Marc might have more insight where the FD issue triggered on
the RK3568.


Heiko

[PATCH 3/3] arm64: dts: rockchip: add CAN-FD nodes for RK3588

[1579567540]

From: luch00 <1579567540@qq.com>

Describe the three CAN-FD controllers integrated in RK3588 in the base
SoC .dtsi.

Add CAN0, CAN1 and CAN2 nodes with their register ranges, interrupts,
clocks and resets, and keep them disabled by default so board DTS files
can enable them as needed.

Signed-off-by: luch00 <1579567540@qq.com>
---
 arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index fc1fdbfd3..f38cd8bd4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -2648,6 +2648,45 @@ dmac1: dma-controller@fea30000 {
 		#dma-cells = <1>;
 	};
 
+	can0: can@fea50000 {
+		compatible = "rockchip,rk3588v2-canfd";
+		reg = <0x0 0xfea50000 0x0 0x1000>;
+		interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
+		clock-names = "baud", "pclk";
+		resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
+		reset-names = "core", "apb";
+		pinctrl-names = "default";
+		pinctrl-0 = <&can0m0_pins>;
+		status = "disabled";
+	};
+
+	can1: can@fea60000 {
+		compatible = "rockchip,rk3588v2-canfd";
+		reg = <0x0 0xfea60000 0x0 0x1000>;
+		interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru CLK_CAN1>, <&cru PCLK_CAN1>;
+		clock-names = "baud", "pclk";
+		resets = <&cru SRST_CAN1>, <&cru SRST_P_CAN1>;
+		reset-names = "core", "apb";
+		pinctrl-names = "default";
+		pinctrl-0 = <&can1m0_pins>;
+		status = "disabled";
+	};
+
+	can2: can@fea70000 {
+		compatible = "rockchip,rk3588v2-canfd";
+		reg = <0x0 0xfea70000 0x0 0x1000>;
+		interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+		clocks = <&cru CLK_CAN2>, <&cru PCLK_CAN2>;
+		clock-names = "baud", "pclk";
+		resets = <&cru SRST_CAN2>, <&cru SRST_P_CAN2>;
+		reset-names = "core", "apb";
+		pinctrl-names = "default";
+		pinctrl-0 = <&can2m0_pins>;
+		status = "disabled";
+	};
+
 	i2c1: i2c@fea90000 {
 		compatible = "rockchip,rk3588-i2c", "rockchip,rk3399-i2c";
 		reg = <0x0 0xfea90000 0x0 0x1000>;
-- 
2.34.1

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

[Cunhao Lu]

Hi Heiko,

thanks for the guidance, and thanks for leaving this to me. :-)

> I don't think we need two people working on this and you did the better
> investigation into the differences, so you should get the credit :-)
>
> So I guess my preference would be to:
> - pick up the erratum 6 into your patch
> - add my haikou patch to the series - that way we also get a user
> - handle Krzysztof's comment from
>   https://lore.kernel.org/linux-rockchip/20260701-sensible-cryptic-ocelot-58035b@quoll/
>
>   as both our bindings have the same structure, so I guess it should be
>
>     oneOf:
>        - enum:
>              rockchip,rk3568v2-canfd
>              rockchip,rk3588v2-canfd
>        - items:
>            - const: rockchip,rk3568v3-canfd
>            - const: rockchip,rk3568v2-canfd
>
> And submit that as v2.

That works for me. I will prepare a v2 with:

- the binding schema changed to use enum as suggested by Krzysztof
- RKCANFD_QUIRK_RK3568_ERRATUM_6 enabled for RK3588v2
- your Haikou patch added to the series

> But if it actually works, then personally I'm more than fine with
> enabling CAN-FD :-D .
>
> I guess Marc might have more insight where the FD issue triggered on
> the RK3568.

I will also double-check that CAN-FD still works with the v2 changes and
wait for Marc's feedback on the CAN-FD issue before deciding whether
RKCANFD_QUIRK_CANFD_BROKEN should stay disabled for RK3588v2.

Thanks,
Cunhao Lu

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

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On 02.07.2026 10:53:53, Cunhao Lu wrote:
> That works for me. I will prepare a v2 with:
>
> - the binding schema changed to use enum as suggested by Krzysztof
> - RKCANFD_QUIRK_RK3568_ERRATUM_6 enabled for RK3588v2
> - your Haikou patch added to the series

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.

> > But if it actually works, then personally I'm more than fine with
> > enabling CAN-FD :-D .
> >
> > I guess Marc might have more insight where the FD issue triggered on
> > the RK3568.
>
> I will also double-check that CAN-FD still works with the v2 changes and
> wait for Marc's feedback on the CAN-FD issue before deciding whether
> RKCANFD_QUIRK_CANFD_BROKEN should stay disabled for RK3588v2.

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

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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Cunhao Lu]

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.

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.

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?

Thanks,
Cunhao Lu

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

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]

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   |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Cunhao Lu]

Hi Marc,

thanks for the feedback.

> Then CAN-FD is broken. :/
>
> Maybe in a later patch we can hack something, to allow working
> configurations.

Understood. I will keep CAN-FD disabled for RK3588 in v2.

I will also try to investigate whether the failing BRS/data-phase setup
can be fixed. If I can find a proper fix, I will send it as a follow-up
patch instead of mixing it into this v2 series.

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

Yes. I will update the RK3588 quirk description and add the reproduce
steps for the BRS/data bitrate issue.

> Please keep it disabled for now.

I will keep RKCANFD_QUIRK_CANFD_BROKEN enabled for RK3588 in v2, so
CAN-FD stays disabled for now.

Thanks,
Cunhao Lu