From: "Heiko Stübner" <heiko@sntech.de>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
linux-can <linux-can@vger.kernel.org>,
1579567540@qq.com
Cc: Vincent Mailhol <mailhol@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
kernel <kernel@pengutronix.de>,
Conor Dooley <conor+dt@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Shengjiu Wang <shengjiu.wang@nxp.com>,
Pengpeng Hou <pengpeng@iscas.ac.cn>,
Russell King <rmk+kernel@armlinux.org.uk>,
Eric Biggers <ebiggers@kernel.org>,
Mario Limonciello <mario.limonciello@amd.com>,
Karl Mehltretter <kmehltretter@gmail.com>,
Yixun Lan <dlan@kernel.org>, Stephen Boyd <sboyd@kernel.org>,
devicetree <devicetree@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-rockchip <linux-rockchip@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Cunhao Lu <1579567540@qq.com>,
Heiko Stuebner <heiko.stuebner@cherry.de>
Subject: Re: [PATCH v2 2/4] can: rockchip: add RK3588 CAN support
Date: Thu, 02 Jul 2026 18:02:25 +0200 [thread overview]
Message-ID: <3527453.usfYGdeWWP@diego> (raw)
In-Reply-To: <tencent_F077D309CDB6CC4802CC086D8009E29BDF06@qq.com>
Am Donnerstag, 2. Juli 2026, 16:06:52 Mitteleuropäische Sommerzeit schrieb 1579567540@qq.com:
> From: Cunhao Lu <1579567540@qq.com>
>
> Add support for the RK3588 CAN 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, RK3588
> encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
> SoC-specific handling.
>
> The RX FIFO count bitfield difference was found by comparing Rockchip's
> vendor kernel 6.1 CAN support for RK3568 and RK3588. Runtime testing on
> RK3588 also confirms that bits 7:5 are needed.
>
> Enable the existing erratum 5 empty-FIFO workaround for RK3588.
> Heiko reproduced erratum 6 on RK3588, so enable that workaround as
> well.
>
> Keep RKCANFD_QUIRK_CANFD_BROKEN enabled for RK3588, so CAN-FD stays
> disabled for now. Local testing did not reproduce the two known CAN-FD
> trigger frames that cause Error Interrupts on RK3568 variants. Instead,
> RK3588 shows a different CAN-FD failure mode: CAN-FD frames without BRS
> work in this setup, but BRS with a data bitrate different from the
> nominal bitrate immediately drives the controller bus-off.
>
> Reported-by: Heiko Stuebner <heiko.stuebner@cherry.de>
> Link: https://lore.kernel.org/lkml/20260630164336.3444550-4-heiko@sntech.de/
I think you might want to drop that above. If anything a Co-developed-by
would be applicable, but from the (small) size of the change, that also
isn't really necessary for me :-)
> Signed-off-by: Cunhao Lu <1579567540@qq.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-07-02 16:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260702140654.2961561-1-1579567540@qq.com>
2026-07-02 14:06 ` [PATCH v2 1/4] dt-bindings: can: rockchip: add rk3588 CAN-FD compatible 1579567540
2026-07-02 14:23 ` Krzysztof Kozlowski
2026-07-02 15:25 ` Cunhao Lu
2026-07-02 16:01 ` Heiko Stübner
2026-07-02 16:32 ` Cunhao Lu
2026-07-02 16:39 ` Krzysztof Kozlowski
2026-07-02 16:42 ` Heiko Stübner
2026-07-02 14:06 ` [PATCH v2 2/4] can: rockchip: add RK3588 CAN support 1579567540
2026-07-02 16:02 ` Heiko Stübner [this message]
2026-07-02 16:34 ` Cunhao Lu
2026-07-02 16:36 ` Heiko Stübner
2026-07-02 14:06 ` [PATCH v2 3/4] arm64: dts: rockchip: add CAN-FD nodes for RK3588 1579567540
2026-07-02 14:06 ` [PATCH v2 4/4] arm64: dts: rockchip: Enable CAN controller on RK3588-Tiger-Haikou 1579567540
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3527453.usfYGdeWWP@diego \
--to=heiko@sntech.de \
--cc=1579567540@qq.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlan@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=ebiggers@kernel.org \
--cc=heiko.stuebner@cherry.de \
--cc=kernel@pengutronix.de \
--cc=kmehltretter@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mailhol@kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mkl@pengutronix.de \
--cc=pengpeng@iscas.ac.cn \
--cc=rmk+kernel@armlinux.org.uk \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=shengjiu.wang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox