From: Vincent Mailhol <mailhol@kernel.org>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-can@vger.kernel.org, linux-kernel@vger.kernel.org,
Vincent Mailhol <mailhol@kernel.org>
Subject: [PATCH v2 4/4] can: enable CAN XL for virtual CAN devices by default
Date: Tue, 23 Sep 2025 13:52:44 +0900 [thread overview]
Message-ID: <20250923-can-fix-mtu-v2-4-984f9868db69@kernel.org> (raw)
In-Reply-To: <20250923-can-fix-mtu-v2-0-984f9868db69@kernel.org>
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 <mailhol@kernel.org>
---
drivers/net/can/vcan.c | 2 +-
drivers/net/can/vxcan.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index f67e858071007acd5f34fa00a76212f1a77997a6..fdc662aea2798125b3aa373f09958363b427ced2 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -156,7 +156,7 @@ static const struct ethtool_ops vcan_ethtool_ops = {
static void vcan_setup(struct net_device *dev)
{
dev->type = ARPHRD_CAN;
- dev->mtu = CANFD_MTU;
+ dev->mtu = CANXL_MTU;
dev->hard_header_len = 0;
dev->addr_len = 0;
dev->tx_queue_len = 0;
diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c
index 99a78a75716749bf858cc78eadb41ca2588fcf94..b2c19f8c5f8e5101b8be343401afe9a4f388c4da 100644
--- a/drivers/net/can/vxcan.c
+++ b/drivers/net/can/vxcan.c
@@ -156,7 +156,7 @@ static void vxcan_setup(struct net_device *dev)
struct can_ml_priv *can_ml;
dev->type = ARPHRD_CAN;
- dev->mtu = CANFD_MTU;
+ dev->mtu = CANXL_MTU;
dev->hard_header_len = 0;
dev->addr_len = 0;
dev->tx_queue_len = 0;
--
2.49.1
next prev parent reply other threads:[~2025-09-23 4:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 4:52 [PATCH v2 0/4] can: rework the CAN MTU logic (CAN XL preparation step 2/3) Vincent Mailhol
2025-09-23 4:52 ` [PATCH v2 1/4] can: annotate mtu accesses with READ_ONCE() Vincent Mailhol
2025-09-23 4:52 ` [PATCH v2 2/4] can: dev: turn can_set_static_ctrlmode() into a non-inline function Vincent Mailhol
2025-09-23 4:52 ` [PATCH v2 3/4] can: populate the minimum and maximum MTU values Vincent Mailhol
2025-09-23 4:52 ` Vincent Mailhol [this message]
2025-09-23 5:13 ` [PATCH v2 0/4] can: rework the CAN MTU logic (CAN XL preparation step 2/3) Vincent Mailhol
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=20250923-can-fix-mtu-v2-4-984f9868db69@kernel.org \
--to=mailhol@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkl@pengutronix.de \
--cc=socketcan@hartkopp.net \
/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
all inboxes | Powered by JetHome®