summaryrefslogtreecommitdiffstats
path: root/drivers/net/can
Commit message (Collapse)AuthorAgeFilesLines
* can: netlink: avoid call to do_set_data_bittiming callback with stale ↵Stefan Mätje2024-10-101-51/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | can_priv::ctrlmode [ Upstream commit 2423cc20087ae9a7b7af575aa62304ef67cad7b6 ] This patch moves the evaluation of data[IFLA_CAN_CTRLMODE] in function can_changelink in front of the evaluation of data[IFLA_CAN_BITTIMING]. This avoids a call to do_set_data_bittiming providing a stale can_priv::ctrlmode with a CAN_CTRLMODE_FD flag not matching the requested state when switching between a CAN Classic and CAN-FD bitrate. In the same manner the evaluation of data[IFLA_CAN_CTRLMODE] in function can_validate is also moved in front of the evaluation of data[IFLA_CAN_BITTIMING]. This is a preparation for patches where the nominal and data bittiming may have interdependencies on the driver side depending on the CAN_CTRLMODE_FD flag state. Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Link: https://patch.msgid.link/20240808164224.213522-1-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FDStefan Mätje2024-10-041-5/+1
| | | | | | | | | | | | | | | | | | | commit 75b3189540578f96b4996e4849b6649998f49455 upstream. Remove the CAN_CTRLMODE_3_SAMPLES announcement for CAN-USB/3-FD devices because these devices don't support it. The hardware has a Microchip SAM E70 microcontroller that uses a Bosch MCAN IP core as CAN FD controller. But this MCAN core doesn't support triple sampling. Fixes: 80662d943075 ("can: esd_usb: Add support for esd CAN-USB/3") Cc: stable@vger.kernel.org Signed-off-by: Stefan Mätje <stefan.maetje@esd.eu> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20240904222740.2985864-2-stefan.maetje@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: m_can: m_can_close(): stop clocks after device has been shut downMarc Kleine-Budde2024-10-041-1/+1
| | | | | | | | | | | | | | | | | | [ Upstream commit 2c09b50efcad985cf920ca88baa9aa52b1999dcc ] After calling m_can_stop() an interrupt may be pending or NAPI might still be executed. This means the driver might still touch registers of the IP core after the clocks have been disabled. This is not good practice and might lead to aborts depending on the SoC integration. To avoid these potential problems, make m_can_close() symmetric to m_can_open(), i.e. stop the clocks at the end, right before shutting down the transceiver. Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Link: https://patch.msgid.link/20240910-can-m_can-fix-ifup-v3-2-6c1720ba45ce@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: enable NAPI before enabling interruptsJake Hamby2024-10-041-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 801ad2f87b0c6d0c34a75a4efd6bfd3a2d9f9298 ] If an interrupt (RX-complete or error flag) is set when bringing up the CAN device, e.g. due to CAN bus traffic before initializing the device, when m_can_start() is called and interrupts are enabled, m_can_isr() is called immediately, which disables all CAN interrupts and calls napi_schedule(). Because napi_enable() isn't called until later in m_can_open(), the call to napi_schedule() never schedules the m_can_poll() callback and the device is left with interrupts disabled and can't receive any CAN packets until rebooted. This can be verified by running "cansend" from another device before setting the bitrate and calling "ip link set up can0" on the test device. Adding debug lines to m_can_isr() shows it's called with flags (IR_EP | IR_EW | IR_CRCE), which calls m_can_disable_all_interrupts() and napi_schedule(), and then m_can_poll() is never called. Move the call to napi_enable() above the call to m_can_start() to enable any initial interrupt flags to be handled by m_can_poll() so that interrupts are reenabled. Add a call to napi_disable() in the error handling section of m_can_open(), to handle the case where later functions return errors. Also, in m_can_close(), move the call to napi_disable() below the call to m_can_stop() to ensure all interrupts are handled when bringing down the device. This race condition is much less likely to occur. Tested on a Microchip SAMA7G54 MPU. The fix should be applicable to any SoC with a Bosch M_CAN controller. Signed-off-by: Jake Hamby <Jake.Hamby@Teledyne.com> Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support") Link: https://patch.msgid.link/20240910-can-m_can-fix-ifup-v3-1-6c1720ba45ce@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: move mcp251xfd_timestamp_start()/stop() into ↵Marc Kleine-Budde2024-09-303-5/+11
| | | | | | | | | | | | | | | | | | | | | | mcp251xfd_chip_start/stop() commit a7801540f325d104de5065850a003f1d9bdc6ad3 upstream. The mcp251xfd wakes up from Low Power or Sleep Mode when SPI activity is detected. To avoid this, make sure that the timestamp worker is stopped before shutting down the chip. Split the starting of the timestamp worker out of mcp251xfd_timestamp_init() into the separate function mcp251xfd_timestamp_start(). Call mcp251xfd_timestamp_init() before mcp251xfd_chip_start(), move mcp251xfd_timestamp_start() to mcp251xfd_chip_start(). In this way, mcp251xfd_timestamp_stop() can be called unconditionally by mcp251xfd_chip_stop(). Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: mcp251xfd: properly indent labelsMarc Kleine-Budde2024-09-304-20/+20
| | | | | | | | | commit 51b2a721612236335ddec4f3fb5f59e72a204f3a upstream. To fix the coding style, remove the whitespace in front of labels. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: mcp251xfd: mcp251xfd_ring_init(): check TX-coalescing configurationMarc Kleine-Budde2024-09-301-3/+11
| | | | | | | | | | | | | | | | | [ Upstream commit ac2b81eb8b2d104033560daea886ee84531e3d0a ] When changing the interface from CAN-CC to CAN-FD mode the old coalescing parameters are re-used. This might cause problem, as the configured parameters are too big for CAN-FD mode. During testing an invalid TX coalescing configuration has been seen. The problem should be been fixed in the previous patch, but add a safeguard here to ensure that the number of TEF coalescing buffers (if configured) is exactly the half of all TEF buffers. Link: https://lore.kernel.org/all/20240805-mcp251xfd-fix-ringconfig-v1-2-72086f0ca5ee@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Limit coalescing to peripheral instancesMarkus Schneider-Pargmann2024-09-301-7/+9
| | | | | | | | | | | | | [ Upstream commit e443d15b949952ee039b731d5c35bcbafa300024 ] The use of coalescing for non-peripheral chips in the current implementation is limited to non-existing. Disable the possibility to set coalescing through ethtool. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-8-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: rx: add workaround for erratum DS80000789E 6 of mcp2518fdMarc Kleine-Budde2024-09-123-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 24436be590c6fbb05f6161b0dfba7d9da60214aa ] This patch tries to works around erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. In the bad case, the driver reads a too large head index. In the original code, the driver always trusted the read value, which caused old, already processed CAN frames or new, incompletely written CAN frames to be (re-)processed. To work around this issue, keep a per FIFO timestamp [1] of the last valid received CAN frame and compare against the timestamp of every received CAN frame. If an old CAN frame is detected, abort the iteration and mark the number of valid CAN frames as processed in the chip by incrementing the FIFO's tail index. Further tests showed that this workaround can recognize old CAN frames, but a small time window remains in which partially written CAN frames [2] are not recognized but then processed. These CAN frames have the correct data and time stamps, but the DLC has not yet been updated. [1] As the raw timestamp overflows every 107 seconds (at the usual clock rate of 40 MHz) convert it to nanoseconds with the timecounter framework and use this to detect stale CAN frames. Link: https://lore.kernel.org/all/BL3PR11MB64844C1C95CA3BDADAE4D8CCFBC99@BL3PR11MB6484.namprd11.prod.outlook.com [2] Reported-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Closes: https://lore.kernel.org/all/FR0P281MB1966273C216630B120ABB6E197E89@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: clarify the meaning of timestampMarc Kleine-Budde2024-09-125-38/+43
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e793c724b48ca8cae9693bc3be528e85284c126a ] The mcp251xfd chip is configured to provide a timestamp with each received and transmitted CAN frame. The timestamp is derived from the internal free-running timer, which can also be read from the TBC register via SPI. The timer is 32 bits wide and is clocked by the external oscillator (typically 20 or 40 MHz). To avoid confusion, we call this timestamp "timestamp_raw" or "ts_raw" for short. Using the timecounter framework, the "ts_raw" is converted to 64 bit nanoseconds since the epoch. This is what we call "timestamp". This is a preparation for the next patches which use the "timestamp" to work around a bug where so far only the "ts_raw" is used. Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: 24436be590c6 ("can: mcp251xfd: rx: add workaround for erratum DS80000789E 6 of mcp2518fd") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: rx: prepare to workaround broken RX FIFO head index erratumMarc Kleine-Budde2024-09-123-47/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 85505e585637a737e4713c1386c30e37c325b82e ] This is a preparatory patch to work around erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. When handling the RX interrupt, the driver iterates over all pending FIFOs (which are implemented as ring buffers in hardware) and reads the FIFO header index from the RX FIFO STA register of the chip. In the bad case, the driver reads a too large head index. In the original code, the driver always trusted the read value, which caused old CAN frames that were already processed, or new, incompletely written CAN frames to be (re-)processed. Instead of reading and trusting the head index, read the head index and calculate the number of CAN frames that were supposedly received - replace mcp251xfd_rx_ring_update() with mcp251xfd_get_rx_len(). The mcp251xfd_handle_rxif_ring() function reads the received CAN frames from the chip, iterates over them and pushes them into the network stack. Prepare that the iteration can be stopped if an old CAN frame is detected. The actual code to detect old or incomplete frames and abort will be added in the next patch. Link: https://lore.kernel.org/all/BL3PR11MB64844C1C95CA3BDADAE4D8CCFBC99@BL3PR11MB6484.namprd11.prod.outlook.com Reported-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Closes: https://lore.kernel.org/all/FR0P281MB1966273C216630B120ABB6E197E89@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: mcp251xfd_handle_rxif_ring_uinc(): factor out in separate ↵Marc Kleine-Budde2024-09-121-16/+32
| | | | | | | | | | | | | | | | | | | | | function [ Upstream commit d49184b7b585f9da7ee546b744525f62117019f6 ] This is a preparation patch. Sending the UINC messages followed by incrementing the tail pointer will be called in more than one place in upcoming patches, so factor this out into a separate function. Also make mcp251xfd_handle_rxif_ring_uinc() safe to be called with a "len" of 0. Tested-by: Stefan Althöfer <Stefan.Althoefer@janztec.com> Tested-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: 85505e585637 ("can: mcp251xfd: rx: prepare to workaround broken RX FIFO head index erratum") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: kvaser_pciefd: Use a single write when releasing RX buffersMartin Jocic2024-09-121-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dd885d90c047dbdd2773c1d33954cbd8747d81e2 ] Kvaser's PCIe cards uses the KCAN FPGA IP block which has dual 4K buffers for incoming messages shared by all (currently up to eight) channels. While the driver processes messages in one buffer, new incoming messages are stored in the other and so on. The design of KCAN is such that a buffer must be fully read and then released. Releasing a buffer will make the FPGA switch buffers. If the other buffer contains at least one incoming message the FPGA will also instantly issue a new interrupt, if not the interrupt will be issued after receiving the first new message. With IRQx interrupts, it takes a little time for the interrupt to happen, enough for any previous ISR call to do it's business and return, but MSI interrupts are way faster so this time is reduced to almost nothing. So with MSI, releasing the buffer HAS to be the very last action of the ISR before returning, otherwise the new interrupt might be "masked" by the kernel because the previous ISR call hasn't returned. And the interrupts are edge-triggered so we cannot loose one, or the ping-pong reading process will stop. This is why this patch modifies the driver to use a single write to the SRB_CMD register before returning. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://patch.msgid.link/20240830153113.2081440-1-martin.jocic@kvaser.com Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: kvaser_pciefd: Move reset of DMA RX buffers to the end of the ISRMartin Jocic2024-09-121-12/+18
| | | | | | | | | | | | | | | [ Upstream commit 48f827d4f48f5243e37b9240029ce3f456d1f490 ] A new interrupt is triggered by resetting the DMA RX buffers. Since MSI interrupts are faster than legacy interrupts, the reset of the DMA buffers must be moved to the very end of the ISR, otherwise a new MSI interrupt will be masked by the current one. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Link: https://lore.kernel.org/all/20240620181320.235465-2-martin.jocic@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: kvaser_pciefd: Rename board_irq to pci_irqMartin Jocic2024-09-121-4/+4
| | | | | | | | | | | | | [ Upstream commit cbf88a6ba7bb6ce0d3131b119298f73bd7b18459 ] Rename the variable name board_irq in the ISR to pci_irq to be more specific and to match the macro by which it is read. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Link: https://lore.kernel.org/all/20240614151524.2718287-7-martin.jocic@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: kvaser_pciefd: Remove unnecessary commentMartin Jocic2024-09-121-1/+0
| | | | | | | | | | | | [ Upstream commit 11d186697ceb10b68c6a1fd505635346b1ccd055 ] The code speaks for itself. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Link: https://lore.kernel.org/all/20240614151524.2718287-4-martin.jocic@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: kvaser_pciefd: Skip redundant NULL pointer check in ISRMartin Jocic2024-09-121-6/+0
| | | | | | | | | | | | | | | | | [ Upstream commit ac765219c2c4e44f29063724c8d36435a3e61985 ] This check is already done at the creation of the net devices in kvaser_pciefd_setup_can_ctrls called from kvaser_pciefd_probe. If it fails, the driver won't load, so there should be no need to repeat the check inside the ISR. The number of channels is read from the FPGA and should be trusted. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Link: https://lore.kernel.org/all/20240614151524.2718287-3-martin.jocic@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: dd885d90c047 ("can: kvaser_pciefd: Use a single write when releasing RX buffers") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: fix ring configuration when switching from CAN-CC to CAN-FD modeMarc Kleine-Budde2024-09-122-4/+27
| | | | | | | | | | | | | | | | [ Upstream commit 50ea5449c56310d2d31c28ba91a59232116d3c1e ] If the ring (rx, tx) and/or coalescing parameters (rx-frames-irq, tx-frames-irq) have been configured while the interface was in CAN-CC mode, but the interface is brought up in CAN-FD mode, the ring parameters might be too big. Use the default CAN-FD values in this case. Fixes: 9263c2e92be9 ("can: mcp251xfd: ring: add support for runtime configurable RX/TX ring parameters") Link: https://lore.kernel.org/all/20240805-mcp251xfd-fix-ringconfig-v1-1-72086f0ca5ee@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Reset cached active_interrupts on startMarkus Schneider-Pargmann2024-09-121-0/+1
| | | | | | | | | | | | | [ Upstream commit 733dbf556cd5b71d5e6f6aa7a93f117b438ab785 ] To force writing the enabled interrupts, reset the active_interrupts cache. Fixes: 07f25091ca02 ("can: m_can: Implement receive coalescing") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-7-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: disable_all_interrupts, not clear active_interruptsMarkus Schneider-Pargmann2024-09-121-1/+0
| | | | | | | | | | | | | | [ Upstream commit a572fea86c9b06cd3e6e89d79d565b52cb7e7cff ] active_interrupts is a cache for the enabled interrupts and not the global masking of interrupts. Do not clear this variable otherwise we may loose the state of the interrupts. Fixes: 07f25091ca02 ("can: m_can: Implement receive coalescing") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-6-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Do not cancel timer from within timerMarkus Schneider-Pargmann2024-09-121-15/+42
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 4d5159bfafa8d1a205d8213b7434e0402588b9ed ] On setups without interrupts, the interrupt handler is called from a timer callback. For non-peripheral receives napi is scheduled, interrupts are disabled and the timer is canceled with a blocking call. In case of an error this can happen as well. Check if napi is scheduled in the timer callback after the interrupt handler executed. If napi is scheduled, the timer is disabled. It will be reenabled by m_can_poll(). Return error values from the interrupt handler so that interrupt threads and timer callback can deal differently with it. In case of the timer we only disable the timer. The rest will be done when stopping the interface. Fixes: b382380c0d2d ("can: m_can: Add hrtimer to generate software interrupt") Fixes: a163c5761019 ("can: m_can: Start/Cancel polling timer together with interrupts") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-5-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Remove m_can_rx_peripheral indirectionMarkus Schneider-Pargmann2024-09-121-17/+1
| | | | | | | | | | | | | | | | | [ Upstream commit 40e4552eeef0e3090a5988de15889795936fd38f ] m_can_rx_peripheral() is a wrapper around m_can_rx_handler() that calls m_can_disable_all_interrupts() on error. The same handling for the same error path is done in m_can_isr() as well. So remove m_can_rx_peripheral() and do the call from m_can_isr() directly. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-4-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Stable-dep-of: 4d5159bfafa8 ("can: m_can: Do not cancel timer from within timer") Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Remove coalesing disable in isr during suspendMarkus Schneider-Pargmann2024-09-121-3/+1
| | | | | | | | | | | | | | [ Upstream commit 6eff1cead75ff330bb33264424c1da6cc7179ab8 ] We don't need to disable coalescing when the interrupt handler executes while the chip is suspended. The coalescing is already reset during suspend. Fixes: 07f25091ca02 ("can: m_can: Implement receive coalescing") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-3-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Reset coalescing during suspend/resumeMarkus Schneider-Pargmann2024-09-121-3/+13
| | | | | | | | | | | | | | | | | | | [ Upstream commit a651261ac74298535f6d6316ebe27beceb6b17b1 ] During resume the interrupts are limited to IR_RF0N and the chip keeps running. In this case if coalescing is enabled and active we may miss waterlevel interrupts during suspend. It is safer to reset the coalescing by stopping the timer and adding IR_RF0N | IR_TEFN to the interrupts. This is a theoratical issue and probably extremely rare. Cc: Martin Hundebøll <martin@geanix.com> Fixes: 4a94d7e31cf5 ("can: m_can: allow keeping the transceiver running in suspend") Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240805183047.305630-2-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: m_can: Release irq on error in m_can_openSimon Horman2024-09-121-1/+4
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 06d4ef3056a7ac31be331281bb7a6302ef5a7f8a ] It appears that the irq requested in m_can_open() may be leaked if an error subsequently occurs: if m_can_start() fails. Address this by calling free_irq in the unwind path for such cases. Flagged by Smatch. Compile tested only. Fixes: eaacfeaca7ad ("can: m_can: Call the RAM init directly from m_can_chip_config") Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/all/20240805-mcan-irq-v2-1-7154c0484819@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_openSimon Arlott2024-09-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 7dd9c26bd6cf679bcfdef01a8659791aa6487a29 upstream. 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() <interrupt> 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 <simon@octiron.net> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> 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 <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: mcp251xfd: tef: update workaround for erratum DS80000789E 6 of mcp2518fdMarc Kleine-Budde2024-08-141-44/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 3a0a88fcbaf9e027ecca3fe8775be9700b4d6460 ] This patch updates the workaround for a problem similar to erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. Erratum DS80000789E 6 says "reading of the FIFOCI bits in the FIFOSTA register for an RX FIFO may be corrupted". However observation shows that this problem is not limited to RX FIFOs but also effects the TEF FIFO. In the bad case, the driver reads a too large head index. As the FIFO is implemented as a ring buffer, this results in re-handling old CAN transmit complete events. Every transmit complete event contains with a sequence number that equals to the sequence number of the corresponding TX request. This way old TX complete events can be detected. If the original driver detects a non matching sequence number, it prints an info message and tries again later. As wrong sequence numbers can be explained by the erratum DS80000789E 6, demote the info message to debug level, streamline the code and update the comments. Keep the behavior: If an old CAN TX complete event is detected, abort the iteration and mark the number of valid CAN TX complete events as processed in the chip by incrementing the FIFO's tail index. Cc: Stefan Althöfer <Stefan.Althoefer@janztec.com> Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: mcp251xfd: tef: prepare to workaround broken TEF FIFO tail index erratumMarc Kleine-Budde2024-08-143-26/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit b8e0ddd36ce9536ad7478dd27df06c9ae92370ba ] This is a preparatory patch to work around a problem similar to erratum DS80000789E 6 of the mcp2518fd, the other variants of the chip family (mcp2517fd and mcp251863) are probably also affected. Erratum DS80000789E 6 says "reading of the FIFOCI bits in the FIFOSTA register for an RX FIFO may be corrupted". However observation shows that this problem is not limited to RX FIFOs but also effects the TEF FIFO. When handling the TEF interrupt, the driver reads the FIFO header index from the TEF FIFO STA register of the chip. In the bad case, the driver reads a too large head index. In the original code, the driver always trusted the read value, which caused old CAN transmit complete events that were already processed to be re-processed. Instead of reading and trusting the head index, read the head index and calculate the number of CAN frames that were supposedly received - replace mcp251xfd_tef_ring_update() with mcp251xfd_get_tef_len(). The mcp251xfd_handle_tefif() function reads the CAN transmit complete events from the chip, iterates over them and pushes them into the network stack. The original driver already contains code to detect old CAN transmit complete events, that will be updated in the next patch. Cc: Stefan Althöfer <Stefan.Althoefer@janztec.com> Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
* can: kvaser_usb: Explicitly initialize family in leafimx driver_info structJimmy Assarsson2024-07-011-0/+1
| | | | | | | | | | | | 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 <extja@kvaser.com> Link: https://lore.kernel.org/all/20240628194529.312968-1-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* can: mcp251xfd: fix infinite loop when xmit failsVitor Soares2024-06-213-9/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vitor.soares@toradex.com> 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 <mkl@pengutronix.de>
* can: kvaser_usb: fix return value for hif_usb_send_regoutChen Ni2024-06-211-1/+1
| | | | | | | | | As the potential failure of usb_submit_urb(), it should be better to return the err variable to catch the error. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://lore.kernel.org/all/20240521041020.1519416-1-nichen@iscas.ac.cn Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* net: annotate writes on dev->mtu from ndo_change_mtu()Eric Dumazet2024-05-073-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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 <edumazet@google.com> Reported-by: Simon Horman <horms@kernel.org> Closes: https://lore.kernel.org/netdev/20240505144608.GB67882@kernel.org/ Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Reviewed-by: Simon Horman <horms@kernel.org> Acked-by: Shannon Nelson <shannon.nelson@amd.com> Link: https://lore.kernel.org/r/20240506102812.3025432-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: handle HAS_IOPORT dependenciesNiklas Schnelle2024-04-082-0/+2
| | | | | | | | | | | | | | | | | In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add HAS_IOPORT as dependency for those drivers requiring them. For the DEFXX driver the use of I/O ports is optional and we only need to fence specific code paths. It also turns out that with HAS_IOPORT handled explicitly HAMRADIO does not need the !S390 dependency and successfully builds the bpqether driver. Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Maciej W. Rozycki <macro@orcam.me.uk> Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* can: kvaser_pciefd: Add additional Xilinx interruptsMartin Jocić2024-03-191-2/+2
| | | | | | | | | | | Since Xilinx-based adapters now support up to eight CAN channels, the TX interrupt mask array must have eight elements. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Link: https://lore.kernel.org/all/2ab3c0585c3baba272ede0487182a423a420134b.camel@kvaser.com Fixes: 9b221ba452aa ("can: kvaser_pciefd: Add support for Kvaser PCIe 8xCAN") [mkl: replace Link by Fixes tag] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* can: mcp251xfd: __mcp251xfd_get_berr_counter(): use CAN_BUS_OFF_THRESHOLD ↵Marc Kleine-Budde2024-03-041-1/+1
| | | | | | | | | | | | instead of open coding it Since 3f9c26210cf8 ("can: error: add definitions for the different CAN error thresholds") we have proper defines for the various CAN error thresholds. So make use of it and replace 256 by CAN_BUS_OFF_THRESHOLD. Link: https://lore.kernel.org/all/20240304074503.3584662-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* can: gs_usb: gs_cmd_reset(): use cpu_to_le32() to assign modeMarc Kleine-Budde2024-03-041-1/+1
| | | | | | | | | | The structure gs_device_mode dm::mode is a __le32, use cpu_to_le32() to assign GS_CAN_MODE_RESET. As GS_CAN_MODE_RESET is 0x0, this is basically a no-op. Link: https://lore.kernel.org/all/20240304074540.3584842-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* can: kvaser_pciefd: Add support for Kvaser PCIe 8xCANMartin Jocić2024-03-042-1/+7
| | | | | | | | Add support for new Kvaser pciefd device, PCIe 8xCAN, based on Xilinx FPGA. Signed-off-by: Martin Jocic <martin.jocic@kvaser.com> Link: https://lore.kernel.org/all/2b2c720a788e1904283e354abb320adb5b631d26.camel@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* can: kvaser_usb: Add support for Leaf v3Jimmy Assarsson2024-03-042-0/+4
| | | | | | | | Add support for Kvaser Leaf v3, based on the hydra platform. Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/all/20240223095217.43783-1-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* rtnetlink: prepare nla_put_iflink() to run under RCUEric Dumazet2024-02-261-1/+1
| | | | | | | | | | | We want to be able to run rtnl_fill_ifinfo() under RCU protection instead of RTNL in the future. This patch prepares dev_get_iflink() and nla_put_iflink() to run either with RTNL or RCU held. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'linux-can-next-for-6.9-20240220' of ↵Paolo Abeni2024-02-206-15/+220
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2024-02-20 this is a pull request of 9 patches for net-next/master. The first patch is by Francesco Dolcini and removes a redundant check for pm_clock_support from the m_can driver. Martin Hundebøll contributes 3 patches to the m_can/tcan4x5x driver to allow resume upon RX of a CAN frame. 3 patches by Srinivas Goud add support for ECC statistics to the xilinx_can driver. The last 2 patches are by Oliver Hartkopp and me, target the CAN RAW protocol and fix an error in the getsockopt() for CAN-XL introduced in the previous pull request to net-next (linux-can-next-for-6.9-20240213). linux-can-next-for-6.9-20240220 * tag 'linux-can-next-for-6.9-20240220' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: raw: raw_getsockopt(): reduce scope of err can: raw: fix getsockopt() for new CAN_RAW_XL_VCID_OPTS can: xilinx_can: Add ethtool stats interface for ECC errors can: xilinx_can: Add ECC support dt-bindings: can: xilinx_can: Add 'xlnx,has-ecc' optional property can: tcan4x5x: support resuming from rx interrupt signal can: m_can: allow keeping the transceiver running in suspend dt-bindings: can: tcan4x5x: Document the wakeup-source flag can: m_can: remove redundant check for pm_clock_support ==================== Link: https://lore.kernel.org/r/20240220085130.2936533-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
| * can: xilinx_can: Add ethtool stats interface for ECC errorsSrinivas Goud2024-02-161-0/+64
| | | | | | | | | | | | | | | | | | Add ethtool stats interface for reading FIFO 1bit/2bit ECC errors information. Signed-off-by: Srinivas Goud <srinivas.goud@amd.com> Link: https://lore.kernel.org/all/20240213-xilinx_ecc-v8-3-8d75f8b80771@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| * can: xilinx_can: Add ECC supportSrinivas Goud2024-02-161-4/+101
| | | | | | | | | | | | | | | | | | | | | | Add ECC support for Xilinx CAN Controller, so this driver reports 1bit/2bit ECC errors for FIFO's based on ECC error interrupt. ECC feature for Xilinx CAN Controller selected through 'xlnx,has-ecc' DT property Signed-off-by: Srinivas Goud <srinivas.goud@amd.com> Link: https://lore.kernel.org/all/20240213-xilinx_ecc-v8-2-8d75f8b80771@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| * can: tcan4x5x: support resuming from rx interrupt signalMartin Hundebøll2024-02-141-2/+32
| | | | | | | | | | | | | | | | | | Implement the "wakeup-source" device tree property, so the chip is left running when suspending, and its rx interrupt is used as a wakeup source to resume operation. Signed-off-by: Martin Hundebøll <martin@geanix.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| * can: m_can: allow keeping the transceiver running in suspendMartin Hundebøll2024-02-145-5/+21
| | | | | | | | | | | | | | | | | | Add a flag to the device class structure that leaves the chip in a running state with rx interrupt enabled, so that an m_can device driver can configure and use the interrupt as a wakeup source. Signed-off-by: Martin Hundebøll <martin@geanix.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
| * can: m_can: remove redundant check for pm_clock_supportFrancesco Dolcini2024-02-141-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | m_can_clk_start() already skip starting the clock when clock support is disabled, remove the redundant check in m_can_class_register(). This also solves the imbalance with m_can_clk_stop() that is called afterward in the same function before the return. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240104235723.46931-1-francesco@dolcini.it [mkl: rebased to net-next/main] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2024-02-151-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: net/core/dev.c 9f30831390ed ("net: add rcu safety to rtnl_prop_list_size()") 723de3ebef03 ("net: free altname using an RCU callback") net/unix/garbage.c 11498715f266 ("af_unix: Remove io_uring code for GC.") 25236c91b5ab ("af_unix: Fix task hung while purging oob_skb in GC.") drivers/net/ethernet/renesas/ravb_main.c ed4adc07207d ("net: ravb: Count packets instead of descriptors in GbEth RX path" ) c2da9408579d ("ravb: Add Rx checksum offload support for GbEth") net/mptcp/protocol.c bdd70eb68913 ("mptcp: drop the push_pending field") 28e5c1380506 ("mptcp: annotate lockless accesses around read-mostly fields") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * can: netlink: Fix TDCO calculation using the old data bittimingMaxime Jayat2024-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <maxime.jayat@mobile-devices.fr> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/40579c18-63c0-43a4-8d4c-f3a6c1c0b417@munic.io Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* | can: softing: remove redundant NULL checkDaniil Dulov2024-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | In this case dev cannot be NULL, so remove redundant check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 03fd3cf5a179 ("can: add driver for Softing card") Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Link: https://lore.kernel.org/all/20240211150535.3529-1-d.dulov@aladdin.ru Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* | can: kvaser_pciefd: Add support for Kvaser M.2 PCIe 4xCANJimmy Assarsson2024-02-122-0/+56
| | | | | | | | | | | | | | | | | | Add support for new Kvaser pciefd device, M.2 PCIe 4xCAN, based on Xilinx FPGA. Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/all/20231113134717.515037-1-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
* | can: m_can: Implement transmit submission coalescingMarkus Schneider-Pargmann2024-02-122-4/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | m_can supports submitting multiple transmits with one register write. This is an interesting option to reduce the number of SPI transfers for peripheral chips. The m_can_tx_op is extended with a bool that signals if it is the last transmission and the submit should be executed immediately. The worker then writes the skb to the FIFO and submits it only if the submit bool is set. If it isn't set, the worker will write the next skb which is waiting in the workqueue to the FIFO, etc. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20240207093220.2681425-15-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-12 22:15:33 +0000