kernel/linux.git/drivers/net/can, branch v6.6.39

can: kvaser_usb: Explicitly initialize family in leafimx driver_info struct

2024-07-11T10:49:16+00:00

commit 19d5b2698c35b2132a355c67b4d429053804f8cc upstream. Explicitly set the 'family' driver_info struct member for leafimx. Previously, the correct operation relied on KVASER_LEAF being the first defined value in enum kvaser_usb_leaf_family. Fixes: e6c80e601053 ("can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression") Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20240628194529.312968-1-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: mcp251xfd: fix infinite loop when xmit fails

2024-07-05T07:34:04+00:00

commit d8fb63e46c884c898a38f061c2330f7729e75510 upstream. When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares Link: https://lore.kernel.org/all/20240517134355.770777-1-ivitro@gmail.com [mkl: use more imperative wording in patch description] Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: m_can: Start/Cancel polling timer together with interrupts

2024-03-26T22:19:29+00:00

[ Upstream commit a163c5761019b94258ca655b27b46e82657fd6f5 ] Interrupts are enabled/disabled in more places than just m_can_start() and m_can_stop(). Couple the polling timer with enabling/disabling of all interrupts to achieve equivalent behavior. Cc: Judith Mendez Fixes: b382380c0d2d ("can: m_can: Add hrtimer to generate software interrupt") Signed-off-by: Markus Schneider-Pargmann Reviewed-by: Simon Horman Link: https://lore.kernel.org/all/20240207093220.2681425-2-msp@baylibre.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: netlink: Fix TDCO calculation using the old data bittiming

2024-02-23T08:25:17+00:00

commit 2aa0a5e65eae27dbd96faca92c84ecbf6f492d42 upstream. The TDCO calculation was done using the currently applied data bittiming, instead of the newly computed data bittiming, which means that the TDCO had an invalid value unless setting the same data bittiming twice. Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)") Signed-off-by: Maxime Jayat Reviewed-by: Vincent Mailhol Link: https://lore.kernel.org/all/40579c18-63c0-43a4-8d4c-f3a6c1c0b417@munic.io Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds

2023-11-20T10:59:00+00:00

[ Upstream commit 6411959c10fe917288cbb1038886999148560057 ] If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error. Fixes: a6e4bc530403 ("can: make the number of echo skb's configurable") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-5-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: dev: can_restart(): fix race condition between controller restart and netif_carrier_on()

2023-11-20T10:59:00+00:00

[ Upstream commit 6841cab8c4504835e4011689cbdb3351dec693fd ] This race condition was discovered while updating the at91_can driver to use can_bus_off(). The following scenario describes how the converted at91_can driver would behave. When a CAN device goes into BUS-OFF state, the driver usually stops/resets the CAN device and calls can_bus_off(). This function sets the netif carrier to off, and (if configured by user space) schedules a delayed work that calls can_restart() to restart the CAN device. The can_restart() function first checks if the carrier is off and triggers an error message if the carrier is OK. Then it calls the driver's do_set_mode() function to restart the device, then it sets the netif carrier to on. There is a race window between these two calls. The at91 CAN controller (observed on the sama5d3, a single core 32 bit ARM CPU) has a hardware limitation. If the device goes into bus-off while sending a CAN frame, there is no way to abort the sending of this frame. After the controller is enabled again, another attempt is made to send it. If the bus is still faulty, the device immediately goes back to the bus-off state. The driver calls can_bus_off(), the netif carrier is switched off and another can_restart is scheduled. This occurs within the race window before the original can_restart() handler marks the netif carrier as OK. This would cause the 2nd can_restart() to be called with an OK netif carrier, resulting in an error message. The flow of the 1st can_restart() looks like this: can_restart() // bail out if netif_carrier is OK netif_carrier_ok(dev) priv->do_set_mode(dev, CAN_MODE_START) // enable CAN controller // sama5d3 restarts sending old message // CAN devices goes into BUS_OFF, triggers IRQ // IRQ handler start at91_irq() at91_irq_err_line() can_bus_off() netif_carrier_off() schedule_delayed_work() // IRQ handler end netif_carrier_on() The 2nd can_restart() will be called with an OK netif carrier and the error message will be printed. To close the race window, first set the netif carrier to on, then restart the controller. In case the restart fails with an error code, roll back the netif carrier to off. Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-2-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: dev: can_restart(): don't crash kernel if carrier is OK

2023-11-20T10:59:00+00:00

[ Upstream commit fe5c9940dfd8ba0c73672dddb30acd1b7a11d4c7 ] During testing, I triggered a can_restart() with the netif carrier being OK [1]. The BUG_ON, which checks if the carrier is OK, results in a fatal kernel crash. This is neither helpful for debugging nor for a production system. [1] The root cause is a race condition in can_restart() which will be fixed in the next patch. Do not crash the kernel, issue an error message instead, and continue restarting the CAN device anyway. Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-1-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: etas_es58x: add missing a blank line after declaration

2023-11-20T10:58:59+00:00

[ Upstream commit 4f8005092cafc194ba6a8e5f39626ba0b9f08271 ] Fix below checkpatch warning: WARNING: Missing a blank line after declarations #2233: FILE: drivers/net/can/usb/etas_es58x/es58x_core.c:2233: + int ret = es58x_init_netdev(es58x_dev, ch_idx); + if (ret) { Fixes: d8f26fd689dd ("can: etas_es58x: remove es58x_get_product_info()") Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20230924110914.183898-3-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: etas_es58x: rework the version check logic to silence -Wformat-truncation

2023-11-20T10:58:59+00:00

[ Upstream commit 107e6f6fe6f38577baecf0e01f517c8607a3a625 ] Following [1], es58x_devlink.c now triggers the following format-truncation GCC warnings: drivers/net/can/usb/etas_es58x/es58x_devlink.c: In function ‘es58x_devlink_info_get’: drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:41: warning: ‘%02u’ directive output may be truncated writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-truncation=] 201 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:30: note: directive argument in the range [0, 255] 201 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:201:3: note: ‘snprintf’ output between 9 and 12 bytes into a destination of size 9 201 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 202 | fw_ver->major, fw_ver->minor, fw_ver->revision); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:41: warning: ‘%02u’ directive output may be truncated writing between 2 and 3 bytes into a region of size between 1 and 3 [-Wformat-truncation=] 211 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:30: note: directive argument in the range [0, 255] 211 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:211:3: note: ‘snprintf’ output between 9 and 12 bytes into a destination of size 9 211 | snprintf(buf, sizeof(buf), "%02u.%02u.%02u", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 212 | bl_ver->major, bl_ver->minor, bl_ver->revision); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:38: warning: ‘%03u’ directive output may be truncated writing between 3 and 5 bytes into a region of size between 2 and 4 [-Wformat-truncation=] 221 | snprintf(buf, sizeof(buf), "%c%03u/%03u", | ^~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:30: note: directive argument in the range [0, 65535] 221 | snprintf(buf, sizeof(buf), "%c%03u/%03u", | ^~~~~~~~~~~~~ drivers/net/can/usb/etas_es58x/es58x_devlink.c:221:3: note: ‘snprintf’ output between 9 and 13 bytes into a destination of size 9 221 | snprintf(buf, sizeof(buf), "%c%03u/%03u", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 222 | hw_rev->letter, hw_rev->major, hw_rev->minor); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is not an actual bug because the sscanf() parsing makes sure that the u8 are only two digits long and the u16 only three digits long. Thus below declaration: char buf[max(sizeof("xx.xx.xx"), sizeof("axxx/xxx"))]; allocates just what is needed to represent either of the versions. This warning was known but ignored because, at the time of writing, -Wformat-truncation was not present in the kernel, not even at W=3 [2]. One way to silence this warning is to check the range of all sub version numbers are valid: [0, 99] for u8 and range [0, 999] for u16. The module already has a logic which considers that when all the sub version numbers are zero, the version number is not set. Note that not having access to the device specification, this was an arbitrary decision. This logic can thus be removed in favor of global check that would cover both cases: - the version number is not set (parsing failed) - the version number is not valid (paranoiac check to please gcc) Before starting to parse the product info string, set the version sub-numbers to the maximum unsigned integer thus violating the definitions of struct es58x_sw_version or struct es58x_hw_revision. Then, rework the es58x_sw_version_is_set() and es58x_hw_revision_is_set() functions: remove the check that the sub-numbers are non zero and replace it by a check that they fit in the expected number of digits. This done, rename the functions to reflect the change and rewrite the documentation. While doing so, also add a description of the return value. Finally, the previous version only checked that &es58x_hw_revision.letter was not the null character. Replace this check by an alphanumeric character check to make sure that we never return a special character or a non-printable one and update the documentation of struct es58x_hw_revision accordingly. All those extra checks are paranoid but have the merit to silence the newly introduced W=1 format-truncation warning [1]. [1] commit 6d4ab2e97dcf ("extrawarn: enable format and stringop overflow warnings in W=1") Link: https://git.kernel.org/torvalds/c/6d4ab2e97dcf [2] https://lore.kernel.org/all/CAMZ6Rq+K+6gbaZ35SOJcR9qQaTJ7KR0jW=XoDKFkobjhj8CHhw@mail.gmail.com/ Reported-by: Marc Kleine-Budde Closes: https://lore.kernel.org/linux-can/20230914-carrousel-wrecker-720a08e173e9-mkl@pengutronix.de/ Fixes: 9f06631c3f1f ("can: etas_es58x: export product information through devlink_ops::info_get()") Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20230924110914.183898-2-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: flexcan: remove the auto stop mode for IMX93

2023-10-06T10:54:33+00:00

IMX93 A0 chip involve the internal q-channel handshake in LPCG and CCM to automatically handle the Flex-CAN IPG STOP signal. Only after FLEX-CAN enter stop mode then can support the self-wakeup feature. But meet issue when do the continue system PM stress test. When config the CAN as wakeup source, the first time after system suspend, any data on CAN bus can wakeup the system, this is as expect. But the second time when system suspend, data on CAN bus can't wakeup the system. If continue this test, we find in odd time system enter suspend, CAN can wakeup the system, but in even number system enter suspend, CAN can't wakeup the system. IC find a bug in the auto stop mode logic, and can't fix it easily. So for the new imx93 A1, IC drop the auto stop mode and involve the GPR to support stop mode (used before). IC define a bit in GPR which can trigger the IPG STOP signal to Flex-CAN, let it go into stop mode. And NXP claim to drop IMX93 A0, and only support IMX93 A1. So this patch remove the auto stop mode, and add flag FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR to imx93. Signed-off-by: Haibo Chen Link: https://lore.kernel.org/all/20230726112458.3524165-2-haibo.chen@nxp.com Signed-off-by: Marc Kleine-Budde