From: Marc Kleine-Budde <mkl@pengutronix.de>
To: zhangqing <zhangqing@rock-chips.com>
Cc: linux-arm-kernel@lists.infradead.org, robh@kernel.org,
conor+dt@kernel.org, heiko@sntech.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-can@vger.kernel.org, linux-rockchip@lists.infradead.org,
cl@rock-chips.com, kernel@pengutronix.de, krzk+dt@kernel.org,
mailhol.vincent@wanadoo.fr
Subject: Re: [PATCH v9 3/3] net: can: rockchip: add can for RK3576 Soc
Date: Fri, 14 Nov 2025 14:22:42 +0100 [thread overview]
Message-ID: <20251114-illegal-flounder-of-maturity-edc269-mkl@pengutronix.de> (raw)
In-Reply-To: <3233894e-9409-4b74-a954-0b30064c3c8c@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]
On 14.11.2025 20:14:13, zhangqing wrote:
>
> 在 2025/11/14 19:01, Marc Kleine-Budde 写道:
> > On 14.11.2025 17:55:53, zhangqing wrote:
> > > > > +/* The rk3576 CAN-FD */
> > > > > +static const struct rkcanfd_devtype_data rkcan_devtype_data_rk3576 = {
> > > > > + .model = RKCAN_MODEL_RK3576,
> > > > > + .quirks = RKCANFD_QUIRK_CANFD_BROKEN,
> > > > Is CAN-FD mode broken on the rk3576?
> > > >
> > > > Please test CAN-FD and please do the tests documented near the
> > > > definition of RKCANFD_QUIRK_CANFD_BROKEN:
> > > >
> > > > | Tests on the rk3568v2 and rk3568v3 show that receiving certain
> > > > | CAN-FD frames trigger an Error Interrupt.
> > > > |
> > > > | - Form Error in RX Arbitration Phase: TX_IDLE RX_STUFF_COUNT (0x0a010100) CMD=0 RX=0 TX=0
> > > > | Error-Warning=1 Bus-Off=0
> > > > | To reproduce:
> > > > | host:
> > > > | cansend can0 002##01f
> > > > | DUT:
> > > > | candump any,0:0,#FFFFFFFF -cexdHtA
> > > > |
> > > > | - Form Error in RX Arbitration Phase: TX_IDLE RX_CRC (0x0a010200) CMD=0 RX=0 TX=0
> > > > | Error-Warning=1 Bus-Off=0
> > > > | To reproduce:
> > > > | host:
> > > > | cansend can0 002##07217010000000000
> > > > | DUT:
> > > > | candump any,0:0,#FFFFFFFF -cexdHtA
> > > There is no doubt about the other modifications above. They will be
> > > corrected in version V10.
> > >
> > > CANFD requires authorization and is not supported by default.
> > Can you explain what you mean by authorization? What do you mean by "not
> > supported"?
>
> For RK3576 SoC, the IC hardware design supports CANFD.
> However, a license application is required before it can be used; otherwise,
> there will be legal risks.
INANL. If an SoC is supplied without a license for the IP cores that you
want to use in a product you sell, you must purchase a license from
Bosch:
https://www.bosch-semiconductors.com/products/ip-modules/can-protocol-license/can-protocol-license.html
I don't see why you should restrict the driver to CAN only, if CAN-FD is
functional.
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: 488 bytes --]
next prev parent reply other threads:[~2025-11-14 13:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 7:54 [PATCH v9 0/3] rockchip: add can for RK3576 Soc Elaine Zhang
2025-11-13 7:54 ` [PATCH v9 1/3] dt-bindings: can: rockchip_canfd: add rk3576 CAN controller Elaine Zhang
2025-11-13 19:40 ` Conor Dooley
2025-11-13 7:54 ` [PATCH v9 2/3] net: can: rockchip: Refactor the rkcanfd_devtype_data structure Elaine Zhang
2025-11-13 7:54 ` [PATCH v9 3/3] net: can: rockchip: add can for RK3576 Soc Elaine Zhang
2025-11-13 14:14 ` Marc Kleine-Budde
2025-11-14 9:55 ` zhangqing
2025-11-14 11:01 ` Marc Kleine-Budde
2025-11-14 12:14 ` zhangqing
2025-11-14 13:22 ` Marc Kleine-Budde [this message]
2025-11-14 13:28 ` Marc Kleine-Budde
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=20251114-illegal-flounder-of-maturity-edc269-mkl@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=cl@rock-chips.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=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.vincent@wanadoo.fr \
--cc=robh@kernel.org \
--cc=zhangqing@rock-chips.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;
as well as URLs for NNTP newsgroup(s).