kernel/drivers/net/can/spi/mcp251x.c, branch linux-rolling-stable

can: mcp251x: fix deadlock in error path of mcp251x_open

2026-03-12T11:09:47Z

[ Upstream commit ab3f894de216f4a62adc3b57e9191888cbf26885 ] The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock. Signed-off-by: Alban Bedel Link: https://patch.msgid.link/20260209144706.2261954-1-alban.bedel@lht.dlh.de Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: mcp251x: mcp251x_can_probe(): use dev_err_probe()

2025-10-31T12:17:46Z

The currently used combination of dev_err() plus return leaves a loud error in dmesg even when the error is a deferred probe which gets resolved later. For example a supply that has not been probed yet. Use dev_err_probe() to improve the handling/display of errors. Signed-off-by: Maud Spierings Link: https://patch.msgid.link/20251030-mcp_err-v1-1-eecf737823b7@gocontroll.com 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

net: WQ_PERCPU added to alloc_workqueue users

2025-09-23T00:40:30Z

Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This change adds a new WQ_PERCPU flag at the network subsystem, to explicitly request the use of the per-CPU behavior. Both flags coexist for one release cycle to allow callers to transition their calls. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. All existing users have been updated accordingly. Suggested-by: Tejun Heo Signed-off-by: Marco Crivellari Link: https://patch.msgid.link/20250918142427.309519-4-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski

treewide: rename GPIO set callbacks back to their original names

2025-08-07T08:07:06Z

The conversion of all GPIO drivers to using the .set_rv() and .set_multiple_rv() callbacks from struct gpio_chip (which - unlike their predecessors - return an integer and allow the controller drivers to indicate failures to users) is now complete and the legacy ones have been removed. Rename the new callbacks back to their original names in one sweeping change. Signed-off-by: Bartosz Golaszewski

net: can: mcp251x: use new GPIO line value setter callbacks

2025-06-18T01:04:10Z

struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski Reviewed-by: Vincent Mailhol Reviewed-by: Marc Kleine-Budde Link: https://patch.msgid.link/20250616-gpiochip-set-rv-net-v2-4-cae0b182a552@linaro.org Signed-off-by: Jakub Kicinski

net: can: mcp251x: propagate the return value of mcp251x_spi_write()

2025-06-18T01:04:10Z

Add an integer return value to mcp251x_write_bits() and use it to propagate the one returned by mcp251x_spi_write(). Return that value on error in the request() GPIO callback. Signed-off-by: Bartosz Golaszewski Reviewed-by: Vincent Mailhol Reviewed-by: Marc Kleine-Budde Link: https://patch.msgid.link/20250616-gpiochip-set-rv-net-v2-3-cae0b182a552@linaro.org Signed-off-by: Jakub Kicinski

can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open

2024-08-22T07:47:09Z

The mcp251x_hw_wake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex. CPU0 CPU1 ---- ---- mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlock Use disable_irq_nosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running. Fixes: 8ce8c0abcba3 ("can: mcp251x: only reset hardware as required") Signed-off-by: Simon Arlott Reviewed-by: Przemek Kitszel Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/4fc08687-1d80-43fe-9f0d-8ef8475e75f6@0882a8b5-c6c3-11e9-b005-00805fc181fe.uuid.home.arpa Signed-off-by: Marc Kleine-Budde

can: mcp251x: simplify with spi_get_device_match_data()

2024-06-21T07:46:39Z

Use spi_get_device_match_data() helper to simplify a bit the driver. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/all/20240606142424.129709-2-krzysztof.kozlowski@linaro.org [mkl: add intermediate cast to uintptr_t] Signed-off-by: Marc Kleine-Budde

can: mcp251x: Fix up includes

2024-06-20T09:52:56Z

This driver is including the legacy GPIO header but the only thing it is using from that header is the wrong define for GPIOF_DIR_OUT. Fix it up by using GPIO_LINE_DIRECTION_* macros respectively. Signed-off-by: Andy Shevchenko Reviewed-by: Vincent Mailhol Link: https://lore.kernel.org/all/20240412173332.186685-1-andriy.shevchenko@linux.intel.com Signed-off-by: Marc Kleine-Budde