wireguard-linux/drivers/net/can/rockchip, branch stable

can: rockchip: add RK3588 CAN support

2026-08-17T17:20:37Z

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. CAN-FD is enabled for RK3588. The BRS bus-off issue seen in earlier testing was caused by the transmit delay compensation setting. With RKCANFD_REG_TRANSMIT_DELAY_COMPENSATION programmed to 0 on RK3588, CAN-FD with BRS works in local testing. Tested on an embedfire,rk3588-lubancat-5io board with can0/can1 directly connected, no other device on the bus, 60 Ohm bus termination, and a 300 MHz CAN clock. Runtime testing used 500 kbit/s arbitration bitrate and 1, 3 and 5 Mbit/s data bitrates. The 5 Mbit/s data phase test ran for 15 minutes with cangen using BRS and cansequence on the receiver. Both interfaces reported 9528377 packets and 150667356 bytes, with 0 bus-errors, 0 error-warn, 0 error-pass and 0 bus-off events. Co-developed-by: Heiko Stuebner Signed-off-by: Heiko Stuebner Tested-by: Heiko Stuebner Reviewed-by: Heiko Stuebner Signed-off-by: Cunhao Lu <1579567540@qq.com> Link: https://patch.msgid.link/tencent_207E464D12344B3228096E23A001D6882508@qq.com Signed-off-by: Marc Kleine-Budde

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2025-10-23T17:53:08Z

Cross-merge networking fixes after downstream PR (net-6.18-rc3). No conflicts or adjacent changes. Signed-off-by: Jakub Kicinski

can: rockchip-canfd: rkcanfd_start_xmit(): use can_dev_dropped_skb() instead of can_dropped_invalid_skb()

2025-10-20T15:18:04Z

In addition to can_dropped_invalid_skb(), the helper function can_dev_dropped_skb() checks whether the device is in listen-only mode and discards the skb accordingly. Replace can_dropped_invalid_skb() by can_dev_dropped_skb() to also drop skbs in for listen-only mode. Reported-by: Marc Kleine-Budde Closes: https://lore.kernel.org/all/20251017-bizarre-enchanted-quokka-f3c704-mkl@pengutronix.de/ Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Link: https://patch.msgid.link/20251017-fix-skb-drop-check-v1-3-556665793fa4@pengutronix.de Signed-off-by: Marc Kleine-Budde

can: treewide: remove can_change_mtu()

2025-10-17T07:57:13Z

can_change_mtu() became obsolete by commit 23049938605b ("can: populate the minimum and maximum MTU values"). Now that net_device->min_mtu and net_device->max_mtu are populated, all the checks are already done by dev_validate_mtu() in net/core/dev.c. Remove the net_device_ops->ndo_change_mtu() callback of all the physical interfaces, then remove can_change_mtu(). Only keep the vcan_change_mtu() and vxcan_change_mtu() because the virtual interfaces use their own different MTU logic. The only functional change this patch introduces is that now the user will be able to change the MTU even if the interface is up. This does not matter for Classical CAN and CAN FD because their MTU range is composed of only one value, respectively CAN_MTU and CANFD_MTU. For the upcoming CAN XL, the MTU will be configurable within the CANXL_MIN_MTU to CANXL_MAX_MTU range at any time, even if the interface is up. This is consistent with the other net protocols and does not contradict ISO 11898-1:2024 as having a modifiable MTU is a kernel extension. Signed-off-by: Vincent Mailhol Link: https://patch.msgid.link/20251003-remove-can_change_mtu-v1-1-337f8bc21181@kernel.org Signed-off-by: Marc Kleine-Budde

time/timecounter: Fix the lie that struct cyclecounter is const

2025-07-01T13:38:25Z

In both the read callback for struct cyclecounter, and in struct timecounter, struct cyclecounter is declared as a const pointer. Unfortunatly, a number of users of this pointer treat it as a non-const pointer as it is burried in a larger structure that is heavily modified by the callback function when accessed. This lie had been hidden by the fact that container_of() "casts away" a const attribute of a pointer without any compiler warning happening at all. Fix this all up by removing the const attribute in the needed places so that everyone can see that the structure really isn't const, but can, and is, modified by the users of it. Signed-off-by: Greg Kroah-Hartman Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/2025070124-backyard-hurt-783a@gregkh

can: dev: add struct data_bittiming_params to group FD parameters

2025-05-21T12:33:28Z

This is a preparation patch for the introduction of CAN XL. CAN FD and CAN XL uses similar bittiming parameters. Add one level of nesting for all the CAN FD parameters. Typically: priv->can.data_bittiming; becomes: priv->can.fd.data_bittiming; This way, the CAN XL equivalent (to be introduced later) would be: priv->can.xl.data_bittiming; Add the new struct data_bittiming_params which contains all the data bittiming parameters, including the TDC and the callback functions. This done, update all the CAN FD drivers to make use of the new layout. Acked-by: Oliver Hartkopp Signed-off-by: Vincent Mailhol Link: https://patch.msgid.link/20250501171213.2161572-2-mailhol.vincent@wanadoo.fr [mkl: fix rcar_canfd] Signed-off-by: Marc Kleine-Budde

can: rockchip_canfd: rkcanfd_remove(): fix order of unregistration calls

2025-05-06T13:54:04Z

If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-2-59a9b131589d@pengutronix.de Reviewed-by: Markus Schneider-Pargmann Signed-off-by: Marc Kleine-Budde

can: rockchip_canfd: fix broken quirks checks

2025-04-15T10:23:10Z

First get the devtype_data then check quirks. Fixes: bbdffb341498 ("can: rockchip_canfd: add quirk for broken CAN-FD support") Signed-off-by: Weizhao Ouyang Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250324114416.10160-1-o451686892@gmail.com Signed-off-by: Marc Kleine-Budde

can: rockchip_canfd: rkcanfd_chip_fifo_setup(): remove duplicated setup of RX FIFO

2025-02-19T11:17:40Z

The rockchip_canfd driver doesn't make use of the TXE FIFO. Although the comment states that the TXE FIFO is setup, it's actually a setup of the RX FIFO. The regular setup of the RX FIFO follows. Remove the duplicated setup of the RX FIFO. Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Signed-off-by: Robin van der Gracht Link: https://patch.msgid.link/20250219-rk3568-canfd-v1-1-453869358c72@pengutronix.de Signed-off-by: Marc Kleine-Budde

can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocated

2025-02-08T11:42:56Z

Fix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() to bail out if skb cannot be allocated. Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Cc: stable@vger.kernel.org Signed-off-by: Robin van der Gracht Link: https://patch.msgid.link/20250208-fix-rockchip-canfd-v1-1-ec533c8a9895@pengutronix.de Signed-off-by: Marc Kleine-Budde