kernel/linux.git/drivers/net/can/vcan.c, branch linux-7.0.y

can: propagate CAN device capabilities via ml_priv

2026-01-15T08:52:04+00:00

Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides. With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored. Fixes: 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") Cc: Marc Kleine-Budde Cc: Arnd Bergmann Cc: Vincent Mailhol Signed-off-by: Oliver Hartkopp Link: https://patch.msgid.link/20260109144135.8495-3-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde

can: enable CAN XL for virtual CAN devices by default

2025-09-24T15:05:34+00:00

In commit 97edec3a11cf ("can: enable CAN FD for virtual CAN devices by default"), vcan and vxcan default MTU was set to CANFD_MTU by default. The reason was that users were confused on how to activate CAN FD on virtual interfaces. Following the introduction of CAN XL, the same logic should be applied. Set the MTU to CANXL_MTU by default. The users who really wish to use a Classical CAN only or a CAN FD virtual device can do respectively: $ ip link set vcan0 mtu 16 or $ ip link set vcan0 mtu 72 to force the old behaviour. Signed-off-by: Vincent Mailhol Link: https://patch.msgid.link/20250923-can-fix-mtu-v3-4-581bde113f52@kernel.org Signed-off-by: Marc Kleine-Budde

net: annotate writes on dev->mtu from ndo_change_mtu()

2024-05-07T23:19:14+00:00

Simon reported that ndo_change_mtu() methods were never updated to use WRITE_ONCE(dev->mtu, new_mtu) as hinted in commit 501a90c94510 ("inet: protect against too small mtu values.") We read dev->mtu without holding RTNL in many places, with READ_ONCE() annotations. It is time to take care of ndo_change_mtu() methods to use corresponding WRITE_ONCE() Signed-off-by: Eric Dumazet Reported-by: Simon Horman Closes: https://lore.kernel.org/netdev/20240505144608.GB67882@kernel.org/ Reviewed-by: Jacob Keller Reviewed-by: Sabrina Dubroca Reviewed-by: Simon Horman Acked-by: Shannon Nelson Link: https://lore.kernel.org/r/20240506102812.3025432-1-edumazet@google.com Signed-off-by: Jakub Kicinski

can: dev: add CAN XL support to virtual CAN

2022-09-15T07:08:09+00:00

Make use of new can_skb_get_data_len() helper. Add support for variable CANXL MTU using the new can_is_canxl_dev_mtu(). Acked-by: Vincent Mailhol Signed-off-by: Oliver Hartkopp Link: https://lore.kernel.org/all/20220912170725.120748-7-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde

can: tree-wide: advertise software timestamping capabilities

2022-07-28T09:44:01+00:00

Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertised what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). This patch only targets the CAN drivers which *do not* support hardware timestamping. For each of those CAN drivers, implement the get_ts_info() using the generic ethtool_op_get_ts_info(). This way, userland can do: | $ ethtool --show-time-stamping canX to confirm the device timestamping capacities. N.B. the drivers which support hardware timestamping will be migrated in separate patches. Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20220727101641.198847-6-mailhol.vincent@wanadoo.fr [mkl: mscan: add missing mscan_ethtool_ops] Signed-off-by: Marc Kleine-Budde

can: v(x)can: add software tx timestamps

2022-07-28T07:30:36+00:00

TX timestamps were added to the can_put_echo_skb() function of can_dev modules in [1]. However, vcan and vxcan do not rely on that function and as such do not offer TX timestamping. While it could be arguable whether TX timestamps are really needed for virtual interfaces, we prefer to still add it so that all CAN drivers, without exception, support the software TX timestamps. Add a call to skb_tx_timestamp() in the vcan_tx() and vxcan_xmit() functions so that the modules now support TX software timestamps. [1] commit 741b91f1b0ea ("can: dev: can_put_echo_skb(): add software tx timestamps") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=741b91f1b0ea34f00f6a7d4539b767c409291fcf Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20220727101641.198847-5-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde

can: Use netif_rx().

2022-03-06T11:05:31+00:00

Since commit baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.") the function netif_rx() can be used in preemptible/thread context as well as in interrupt context. Use netif_rx(). Cc: Marc Kleine-Budde Cc: Oliver Hartkopp Cc: Wolfgang Grandegger Cc: linux-can@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Acked-by: Oliver Hartkopp Acked-by: Marc Kleine-Budde Signed-off-by: David S. Miller

can: do not increase tx_bytes statistics for RTR frames

2022-01-05T11:09:05+00:00

The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. As such, net_device_stats::tx_bytes should not be increased when sending RTR frames. The function can_get_echo_skb() already returns the correct length, even for RTR frames (c.f. [1]). However, for historical reasons, the drivers do not use can_get_echo_skb()'s return value and instead, most of them store a temporary length (or dlc) in some local structure or array. Using the return value of can_get_echo_skb() solves the issue. After doing this, such length/dlc fields become unused and so this patch does the adequate cleaning when needed. This patch fixes all the CAN drivers. Finally, can_get_echo_skb() is decorated with the __must_check attribute in order to force future drivers to correctly use its return value (else the compiler would emit a warning). [1] commit ed3320cec279 ("can: dev: __can_get_echo_skb(): fix real payload length return value for RTR frames") Link: https://lore.kernel.org/all/20211207121531.42941-6-mailhol.vincent@wanadoo.fr Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Yasushi SHOJI Cc: Oliver Hartkopp Cc: Stephane Grosjean Cc: Andreas Larsson Tested-by: Jimmy Assarsson # kvaser Signed-off-by: Vincent Mailhol Acked-by: Stefan Mätje # esd_usb2 Tested-by: Stefan Mätje # esd_usb2 [mkl: add conversion for grcan] Signed-off-by: Marc Kleine-Budde

net: introduce CAN specific pointer in the struct net_device

2021-02-24T22:32:15+00:00

Since 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv") the CAN framework uses per device specific data in the AF_CAN protocol. For this purpose the struct net_device->ml_priv is used. Later the ml_priv usage in CAN was extended for other users, one of them being CAN_J1939. Later in the kernel ml_priv was converted to an union, used by other drivers. E.g. the tun driver started storing it's stats pointer. Since tun devices can claim to be a CAN device, CAN specific protocols will wrongly interpret this pointer, which will cause system crashes. Mostly this issue is visible in the CAN_J1939 stack. To fix this issue, we request a dedicated CAN pointer within the net_device struct. Reported-by: syzbot+5138c4dd15a0401bec7b@syzkaller.appspotmail.com Fixes: 20dd3850bcf8 ("can: Speed up CAN frame receiption by using ml_priv") Fixes: ffd956eef69b ("can: introduce CAN midlayer private and allocate it automatically") Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Fixes: 497a5757ce4e ("tun: switch to net core provided statistics counters") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20210223070127.4538-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski

can: make use of preallocated can_ml_priv for per device struct can_dev_rcv_lists

2019-09-04T11:29:15+00:00

This patch removes the old method of allocating the per device protocol specific memory via a netdevice_notifier. This had the drawback, that the allocation can fail, leading to a lot of null pointer checks in the code. This also makes the live cycle management of this memory quite complicated. This patch switches from the allocating the struct can_dev_rcv_lists in a NETDEV_REGISTER call to using the dev->ml_priv, which is allocated by the driver since the previous patch. Signed-off-by: Oleksij Rempel Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde