kernel/linux.git/drivers/net/can/slcan, branch master

kernel.h: drop hex.h and update all hex.h users

2026-01-21T03:44:19+00:00

Remove from and update all users/callers of hex.h interfaces to directly #include as part of the process of putting kernel.h on a diet. Removing hex.h from kernel.h means that 36K C source files don't have to pay the price of parsing hex.h for the roughly 120 C source files that need it. This change has been build-tested with allmodconfig on most ARCHes. Also, all users/callers of in the entire source tree have been updated if needed (if not already #included). Link: https://lkml.kernel.org/r/20251215005206.2362276-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Reviewed-by: Andy Shevchenko Cc: Ingo Molnar Cc: Yury Norov (NVIDIA) Signed-off-by: Andrew Morton

can: treewide: remove can_change_mtu()

2025-10-17T07:57:13+00:00

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

can: slcan: allow reception of short error messages

2025-05-21T08:12:05+00:00

Allows slcan to receive short messages (typically errors) from the serial interface. When error support was added to slcan protocol in b32ff4668544e1333b694fcc7812b2d7397b4d6a ("can: slcan: extend the protocol with error info") the minimum valid message size changed from 5 (minimum standard can frame tIII0) to 3 ("e1a" is a valid protocol message, it is one of the examples given in the comments for slcan_bump_err() ), but the check for minimum message length prodicating all decoding was not adjusted. This makes short error messages discarded and error frames not being generated. This patch changes the minimum length to the new minimum (3 characters, excluding terminator, is now a valid message). Signed-off-by: Carlos Sanchez Fixes: b32ff4668544 ("can: slcan: extend the protocol with error info") Reviewed-by: Vincent Mailhol Link: https://patch.msgid.link/20250520102305.1097494-1-carlossanchez@geotab.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde

tty: use u8 for flags

2023-08-11T19:12:45+00:00

This makes all those 'char's an explicit 'u8'. This is part of the continuing unification of chars and flags to be consistent u8. This approaches tty_port_default_receive_buf(). Note that we do not change signedness as we compile with -funsigned-char. Signed-off-by: "Jiri Slaby (SUSE)" Cc: William Hubbs Cc: Chris Brannon Cc: Kirk Reiser Cc: Samuel Thibault Cc: Marcel Holtmann Cc: Johan Hedberg Cc: Luiz Augusto von Dentz Cc: Dmitry Torokhov Cc: Arnd Bergmann Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Max Staudt Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: Dario Binacchi Cc: Andreas Koensgen Cc: Jeremy Kerr Cc: Matt Johnston Cc: Krzysztof Kozlowski Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Acked-by: Mark Brown Link: https://lore.kernel.org/r/20230810091510.13006-18-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

tty: use u8 for chars

2023-08-11T19:12:45+00:00

This makes all those 'unsigned char's an explicit 'u8'. This is part of the continuing unification of chars and flags to be consistent u8. This approaches tty_port_default_receive_buf(). Flags to be next. Signed-off-by: "Jiri Slaby (SUSE)" Cc: William Hubbs Cc: Chris Brannon Cc: Kirk Reiser Cc: Samuel Thibault Cc: Dmitry Torokhov Cc: Arnd Bergmann Cc: Max Staudt Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Dario Binacchi Cc: Andreas Koensgen Cc: Jeremy Kerr Cc: Matt Johnston Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Peter Ujfalusi Acked-by: Mark Brown Link: https://lore.kernel.org/r/20230810091510.13006-17-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

tty: make tty_ldisc_ops::buf() hooks operate on size_t

2023-08-11T19:12:45+00:00

Count passed to tty_ldisc_ops::receive_buf*(), ::lookahead_buf(), and returned from ::receive_buf2() is expected to be size_t. So set it to size_t to unify with the rest of the code. Signed-off-by: "Jiri Slaby (SUSE)" Cc: William Hubbs Cc: Chris Brannon Cc: Kirk Reiser Cc: Samuel Thibault Cc: Marcel Holtmann Cc: Johan Hedberg Cc: Luiz Augusto von Dentz Cc: Dmitry Torokhov Cc: Arnd Bergmann Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Max Staudt Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: Dario Binacchi Cc: Andreas Koensgen Cc: Jeremy Kerr Cc: Matt Johnston Cc: Krzysztof Kozlowski Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Acked-by: Mark Brown Link: https://lore.kernel.org/r/20230810091510.13006-16-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

can: slcan: remove casts from tty->disc_data

2023-07-31T15:16:05+00:00

tty->disc_data is 'void *', so there is no need to cast from that. Therefore remove the casts and assign the pointer directly. Signed-off-by: Jiri Slaby (SUSE) Cc: Dario Binacchi Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Acked-by: Marc Kleine-Budde Link: https://lore.kernel.org/r/20230731080244.2698-6-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman

can: slcan: fix freed work crash

2022-12-07T09:32:24+00:00

The LTP test pty03 is causing a crash in slcan: BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 348 Comm: kworker/0:3 Not tainted 6.0.8-1-default #1 openSUSE Tumbleweed 9d20364b934f5aab0a9bdf84e8f45cfdfae39dab Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (events) RIP: 0010:process_one_work (/home/rich/kernel/linux/kernel/workqueue.c:706 /home/rich/kernel/linux/kernel/workqueue.c:2185) Code: 49 89 ff 41 56 41 55 41 54 55 53 48 89 f3 48 83 ec 10 48 8b 06 48 8b 6f 48 49 89 c4 45 30 e4 a8 04 b8 00 00 00 00 4c 0f 44 e0 <49> 8b 44 24 08 44 8b a8 00 01 00 00 41 83 e5 20 f6 45 10 04 75 0e RSP: 0018:ffffaf7b40f47e98 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffff9d644e1b8b48 RCX: ffff9d649e439968 RDX: 00000000ffff8455 RSI: ffff9d644e1b8b48 RDI: ffff9d64764aa6c0 RBP: ffff9d649e4335c0 R08: 0000000000000c00 R09: ffff9d64764aa734 R10: 0000000000000007 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d649e4335e8 R14: ffff9d64490da780 R15: ffff9d64764aa6c0 FS: 0000000000000000(0000) GS:ffff9d649e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000036424000 CR4: 00000000000006f0 Call Trace: worker_thread (/home/rich/kernel/linux/kernel/workqueue.c:2436) kthread (/home/rich/kernel/linux/kernel/kthread.c:376) ret_from_fork (/home/rich/kernel/linux/arch/x86/entry/entry_64.S:312) Apparently, the slcan's tx_work is freed while being scheduled. While slcan_netdev_close() (netdev side) calls flush_work(&sl->tx_work), slcan_close() (tty side) does not. So when the netdev is never set UP, but the tty is stuffed with bytes and forced to wakeup write, the work is scheduled, but never flushed. So add an additional flush_work() to slcan_close() to be sure the work is flushed under all circumstances. The Fixes commit below moved flush_work() from slcan_close() to slcan_netdev_close(). What was the rationale behind it? Maybe we can drop the one in slcan_netdev_close()? I see the same pattern in can327. So it perhaps needs the very same fix. Fixes: cfcb4465e992 ("can: slcan: remove legacy infrastructure") Link: https://bugzilla.suse.com/show_bug.cgi?id=1205597 Reported-by: Richard Palethorpe Tested-by: Petr Vorel Cc: Dario Binacchi Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: linux-can@vger.kernel.org Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Cc: Max Staudt Signed-off-by: Jiri Slaby (SUSE) Reviewed-by: Max Staudt Link: https://lore.kernel.org/all/20221201073426.17328-1-jirislaby@kernel.org Signed-off-by: Marc Kleine-Budde

can: dev: fix skb drop check

2022-11-07T13:00:27+00:00

In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") the priv->ctrlmode element is read even on virtual CAN interfaces that do not create the struct can_priv at startup. This out-of-bounds read may lead to CAN frame drops for virtual CAN interfaces like vcan and vxcan. This patch mainly reverts the original commit and adds a new helper for CAN interface drivers that provide the required information in struct can_priv. Fixes: a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") Reported-by: Dariusz Stojaczyk Cc: Vincent Mailhol Cc: Max Staudt Signed-off-by: Oliver Hartkopp Acked-by: Vincent Mailhol Link: https://lore.kernel.org/all/20221102095431.36831-1-socketcan@hartkopp.net Cc: stable@vger.kernel.org # 6.0.x [mkl: patch pch_can, too] 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

kernel/linux.git/drivers/net/can/slcan, branch master

kernel.h: drop hex.h and update all hex.h users

can: treewide: remove can_change_mtu()

can: slcan: allow reception of short error messages

tty: use u8 for flags

tty: use u8 for chars

tty: make tty_ldisc_ops::*buf*() hooks operate on size_t

can: slcan: remove casts from tty->disc_data

can: slcan: fix freed work crash

can: dev: fix skb drop check

can: tree-wide: advertise software timestamping capabilities

tty: make tty_ldisc_ops::buf() hooks operate on size_t