From: "Cunhao Lu" <1579567540@qq.com>
To: krzk <krzk@kernel.org>
Cc: "Marc Kleine-Budde" <mkl@pengutronix.de>, heiko <heiko@sntech.de>,
linux-can <linux-can@vger.kernel.org>,
mailhol <mailhol@kernel.org>, kernel <kernel@pengutronix.de>,
robh <robh@kernel.org>, krzk+dt <krzk+dt@kernel.org>,
conor+dt <conor+dt@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>
Subject: Re: [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
Date: Thu, 2 Jul 2026 16:17:25 +0800 [thread overview]
Message-ID: <tencent_97F21396469202221027FD429A6E69DA6409@qq.com> (raw)
Hi Krzysztof,
thanks for the review.
> DT properties have nothing to do here. Are you saying it is fully
> compatible? Then express it properly with fallback.
No, I do not think RK3588v2 is fully compatible with RK3568v2. The RX
FIFO count field uses a different bitfield on RK3588v2, so using
rockchip,rk3568v2-canfd as a fallback would describe a register layout
that does not match the hardware.
Both standard and extended CAN-FD frames worked in my local RK3588v2
testing, but that only confirms CAN-FD functionality on this variant. It
does not make the RK3568v2 register layout a valid fallback for
RK3588v2.
I will reword the commit message in v2 to explain this hardware
difference instead of talking about the DT properties.
> Do not explain what you did. Explain WHY.
>
> Driver is irrelevant here.
Understood. I will remove the driver-focused wording from the binding
patch. The v2 commit message will explain why RK3588v2 needs its own
compatible from the hardware description point of view.
> We do not take anonymous contributions.
I will use my real name in v2.
> So that's just enum with previous entry
I will fold the single-compatible entries into an enum in v2.
> And why is this different from rk3588?
The reason I used rk3588v2 is that this is how the controller identifies
itself at runtime:
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
I also checked Rockchip's vendor kernel 6.1 sources. The RK3588 DTS uses
the binding name "rockchip,can-2.0" for these controllers, while the
upstream driver has SoC-specific compatibles for the Rockchip CAN-FD IP.
That is why I chose the SoC/IP variant name rockchip,rk3588v2-canfd.
If the preferred binding name is rockchip,rk3588-canfd instead, I can
change the compatible in v2.
Thanks,
Cunhao Lu
next reply other threads:[~2026-07-02 8:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 8:17 Cunhao Lu [this message]
2026-07-02 8:49 ` [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible Marc Kleine-Budde
-- strict thread matches above, loose matches on Subject: below --
2026-07-02 8:57 Cunhao Lu
[not found] <20260701070128.2096267-1-1579567540@qq.com>
2026-07-01 7:01 ` 1579567540
2026-07-02 7:43 ` Krzysztof Kozlowski
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=tencent_97F21396469202221027FD429A6E69DA6409@qq.com \
--to=1579567540@qq.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=kernel@pengutronix.de \
--cc=krzk+dt@kernel.org \
--cc=krzk@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=mkl@pengutronix.de \
--cc=robh@kernel.org \
/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