summaryrefslogtreecommitdiff
path: root/drivers/net/can
AgeCommit message (Collapse)Author
2023-06-22can: rx-offload: fix coding styleMarc Kleine-Budde
This patch aligns code to match open parenthesis. Link: https://lore.kernel.org/all/20230620131130.240180-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: m_can: fix coding styleMarc Kleine-Budde
This patch aligns code to match open parenthesis and removes a trailing whitespace. Fixes: eb38c2053b67 ("can: rx-offload: rename can_rx_offload_queue_sorted() -> can_rx_offload_queue_timestamp()") Fixes: f5071d9e729d ("can: m_can: m_can_handle_bus_errors(): add support for handling DLEC error on CAN-FD frames") Reported-by: Judith Mendez <jm@ti.com> Link: https://lore.kernel.org/all/20230523062410.1984098-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCsMiquel Raynal
In their RZN1 SoC, Renesas put a CAN controller supposed to act very similarly to the original Philips sja1000. In practice, while flooding the bus with another device, we discovered that the controller very often after an overrun situation would just refuse any new frame, drop them all and trigger over and over again the overrun interrupt, even though the buffer would have been totally emptied. The controller acts like if its internal buffer offsets (where it writes and where the host reads) where totally screwed-up. Renesas manual mentions a single action to perform in order to resynchronize the read and write offsets within the buffer: performing a soft reset. Performing a soft reset takes a bit of time and involves small delays, so better do that in a threaded handler rather than inside the hard IRQ handler. Add platform data to recognize the platforms which need this workaround, and when the faulty situation is diagnosed, stop what is being performed and request the threaded handler to be executed in order to perform the reset. Tested-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com> # 5.10 Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/all/20230616134553.2786391-2-miquel.raynal@bootlin.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: sja1000: Prepare the use of a threaded handlerMiquel Raynal
In order to support a flavor of the sja1000 which sometimes freezes, it will be needed upon certain interrupts to perform a soft reset. The soft reset operation takes a bit of time, so better not do it within the hard interrupt handler but rather in a threaded handler. Let's prepare the possibility for sja1000_err() to request "interrupting" the current flow and request the threaded handler to be run while keeping the interrupt line low. There is no functional change. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/all/20230616134553.2786391-1-miquel.raynal@bootlin.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Use consistent prefix ESD_USB_ for macrosFrank Jungclaus
Rename the following macros: - ESD_RTR to ESD_USB_RTR - ESD_EV_CAN_ERROR_EXT to ESD_USB_EV_CAN_ERROR_EXT Additionally remove the double newline trailing to definition of ESD_USB_RTR. Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230523173105.3175086-3-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Make use of kernel macros BIT() and GENMASK()Frank Jungclaus
Make use of kernel macros BIT() and GENMASK(). Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230523173105.3175086-2-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Don't bother the user with nonessential log messageFrank Jungclaus
Replace a netdev_info(), emitting an informational message about the BTR value to be send to the controller, with a debug message by means of netdev_dbg(). Link: https://lore.kernel.org/all/20230509-superglue-hazy-38108aa66bfa-mkl@pengutronix.de/ Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-7-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Replace hardcoded message length given to USB commandsFrank Jungclaus
Replace all hardcoded values supplied to the len element of esd_usb_msg (and its siblings) by more readable expressions, based on sizeof(), offsetof(), etc. Also spend documentation / comments that the len element of esd_usb_msg is in multiples of 32bit words and not in bytes. Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-6-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Prefix all structures with the device nameFrank Jungclaus
Prefix all the structures with the device name. For commonly used structures make use of (the module name) esd_usb_. For esd CAN-USB/2 and CAN-USB/Micro specific structures use esd_usb_2_ and esd_usb_m. Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-5-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Use consistent prefixes for macrosFrank Jungclaus
Add the consistent prefix ESD_USB_ to all macros defined within esd_usb.c. For macros specific to esd CAN-USB/2 use ESD_USB_2_ as prefix. For macros specific to esd CAN-USB/Micro use ESD_USB_M_ as prefix. Change the macro ESD_USB_3_SAMPLES to ESD_USB_TRIPLE_SAMPLES to not mix up with the prefix ESD_USB_3_ which will be introduced for the CAN-USB/3 device. Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-4-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Replace initializer macros used for struct can_bittiming_constFrank Jungclaus
Replace the macros used to initialize the members of struct can_bittiming_const with direct values. Then also use those struct members to do the calculations in esd_usb2_set_bittiming(). Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-3-frank.jungclaus@esd.eu [mkl: esd_usb2_set_bittiming() use esd_usb2_bittiming_const instead of priv->can.bittiming_const] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-22can: esd_usb: Make use of existing kernel macrosFrank Jungclaus
Make use of existing kernel macros: - Use the unit suffixes from linux/units.h for the controller clock frequencies - Use the BIT() and the GENMASK() macro to set specific bits in some constants - Use CAN_MAX_DLEN (instead of directly using the value 8) for the maximum CAN payload length Additionally: - Spend some commenting for the previously changed constants - Add the current year to the copyright notice - While adding the header linux/units.h to the list of include files also sort that list alphabetically Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Link: https://lore.kernel.org/all/CAMZ6RqKdg5YBufa0C+ttzJvoG=9yuti-8AmthCi4jBbd08JEtw@mail.gmail.com/ Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/all/20230518-grower-film-ea8b5f853f3e-mkl@pengutronix.de/ Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-2-frank.jungclaus@esd.eu [mkl: remove hex constants in comments after BIT()] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-22can: dev: add transceiver capabilities to xilinx_canMarcel Hellwig
Currently the xilinx_can driver does not support adding a phy like the "ti,tcan1043" to its devicetree. This code makes it possible to add such phy, so that the kernel makes sure that the PHY is in operational state, when the link is set to an "up" state. Signed-off-by: Marcel Hellwig <git@cookiesoft.de> Link: https://lore.kernel.org/r/20230417085204.179268-1-git@cookiesoft.de [mkl: call phy_power_off() after pm_runtime_put()] [mkl: remove error message for phy_power_on() failure] [mkl: update kernel-doc for struct xcan_priv] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-22can: kvaser_usb: Add len8_dlc supportCarsten Schmidt
Add support for the Classical CAN raw DLC functionality to send and receive DLC values from 9 .. 15. v1: https://lore.kernel.org/all/20230506105529.4023-1-carsten.schmidt-achim@t-online.de Signed-off-by: Carsten Schmidt <carsten.schmidt-achim@t-online.de> Tested-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516125332.82894-1-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-18Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Conflicts: drivers/net/ethernet/freescale/fec_main.c 6ead9c98cafc ("net: fec: remove the xdp_return_frame when lack of tx BDs") 144470c88c5d ("net: fec: using the standard return codes when xdp xmit errors") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17can: kvaser_pciefd: Disable interrupts in probe error pathJimmy Assarsson
Disable interrupts in error path of probe function. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-7-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Do not send EFLUSH command on TFD interruptJimmy Assarsson
Under certain circumstances we send two EFLUSH commands, resulting in two EFLUSH ack packets, while only expecting a single EFLUSH ack. This can cause the driver Tx flush completion to get out of sync. To avoid this problem, don't enable the "Transmit buffer flush done" (TFD) interrupt and remove the code handling it. Now we only send EFLUSH command after receiving status packet with "Init detected" (IDET) bit set. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-6-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Empty SRB buffer in probeJimmy Assarsson
Empty the "Shared receive buffer" (SRB) in probe, to assure we start in a known state, and don't process any irrelevant packets. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-5-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Call request_irq() before enabling interruptsJimmy Assarsson
Make sure the interrupt handler is registered before enabling interrupts. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Clear listen-only bit if not explicitly requestedJimmy Assarsson
The listen-only bit was never cleared, causing the controller to always use listen-only mode, if previously set. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-17can: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop()Jimmy Assarsson
Set can.state to CAN_STATE_STOPPED in kvaser_pciefd_stop(). Without this fix, wrong CAN state was repported after the interface was brought down. Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices") Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Link: https://lore.kernel.org/r/20230516134318.104279-2-extja@kvaser.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: xilinx: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-20-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: ti_hecc: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-19-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: sun4i_can: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Gerhard Bertelsmann <info@gerhard-bertelsmann.de> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20230512212725.143824-18-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: softing: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-17-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: sja1000_platform: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-16-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: sja1000_isa: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-15-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: rcar: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert these drivers from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230512212725.143824-14-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: mscan: mpc5xxx_can: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-13-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: m_can: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-12-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: janz-ican3: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-11-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: ifi_canfd: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-10-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: grcan: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-9-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: flexcan: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-8-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: ctucanfd: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Link: https://lore.kernel.org/r/20230512212725.143824-7-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: cc770_platform: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-6-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: cc770_isa: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-5-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: c_can: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-4-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: bxcan: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230512212725.143824-3-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: at91_can: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230512212725.143824-2-u.kleine-koenig@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: bxcan: Remove unnecessary print function dev_err()Jiapeng Chong
The print function dev_err() is redundant because platform_get_irq_byname() already prints an error. ./drivers/net/can/bxcan.c:970:2-9: line 970 is redundant because platform_get_irq() already prints an error. ./drivers/net/can/bxcan.c:964:2-9: line 964 is redundant because platform_get_irq() already prints an error. ./drivers/net/can/bxcan.c:958:2-9: line 958 is redundant because platform_get_irq() already prints an error. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4878 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/20230506080725.68401-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: usb: f81604: add Fintek F81604 supportJi-Ze Hong
This patch adds support for Fintek USB to 2CAN controller. Changelog: v7: https://lore.kernel.org/all/20230509073821.25289-1-peter_hong@fintek.com.tw 1. Fix consistency of coding style for "break" in f81604_register_urbs(). 2. Remove goto statement in f81604_open(). v6: https://lore.kernel.org/all/20230505022317.22417-1-peter_hong@fintek.com.tw 1. Remove non-used define and change constant mask to GENMASK(). 2. Move some variables declaration from function start to block start. 3. Move some variables initization into declaration. 4. Change variable "id" in f81604_start_xmit() only for CAN ID usage. v5: https://lore.kernel.org/all/20230420024403.13830-1-peter_hong@fintek.com.tw 1. Change all u8 *buff to struct f81604_int_data/f81604_can_frame. 2. Change all netdev->dev_id to netdev->dev_port. 3. Remove over design for f81604_process_rx_packet(). This device only report a frame at once, so the f81604_process_rx_packet() are reduced to process 1 frame. v4: https://lore.kernel.org/all/20230413084253.1524-1-peter_hong@fintek.com.tw 1. Remove f81604_prepare_urbs/f81604_remove_urbs() and alloc URB/buffer dynamically in f81604_register_urbs(), using "urbs_anchor" for manage all rx/int URBs. 2. Add F81604 to MAINTAINERS list. 3. Change handle_clear_reg_work/handle_clear_overrun_work to single clear_reg_work and using bitwise "clear_flags" to record it. 4. Move __f81604_set_termination in front of f81604_probe() to avoid rarely racing condition. 5. Add __aligned to struct f81604_int_data / f81604_sff / f81604_eff. 6. Add aligned operations in f81604_start_xmit/f81604_process_rx_packet(). 7. Change lots of CANBUS functions first parameter from struct usb_device* to struct f81604_port_priv *priv. But remain f81604_write / f81604_read / f81604_update_bits() as struct usb_device* for __f81604_set_termination() in probe() stage. 8. Simplify f81604_read_int_callback() and separate into f81604_handle_tx / f81604_handle_can_bus_errors() functions. v3: https://lore.kernel.org/all/20230327051048.11589-1-peter_hong@fintek.com.tw 1. Change CAN clock to using MEGA units. 2. Remove USB set/get retry, only remain SJA1000 reset/operation retry. 3. Fix all numberic constant to define. 4. Add terminator control. (only 0 & 120 ohm) 5. Using struct data to represent INT/TX/RX endpoints data instead byte arrays. 6. Error message reports changed from %d to %pe for mnemotechnic values. 7. Some bit operations are changed to FIELD_PREP(). 8. Separate TX functions from f81604_read_int_callback(). 9. cf->can_id |= CAN_ERR_CNT in f81604_read_int_callback to report valid TX/RX error counts. 10. Move f81604_prepare_urbs/f81604_remove_urbs() from CAN open/close() to USB probe/disconnect(). 11. coding style refactoring. v2: https://lore.kernel.org/all/20230321081152.26510-1-peter_hong@fintek.com.tw 1. coding style refactoring. 2. some const number are defined to describe itself. 3. fix wrong usage for can_get_echo_skb() in f81604_write_bulk_callback(). v1: https://lore.kernel.org/all/20230317093352.3979-1-peter_hong@fintek.com.tw Signed-off-by: Ji-Ze Hong (Peter Hong) <peter_hong@fintek.com.tw> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20230509073821.25289-1-peter_hong@fintek.com.tw [mkl: add changelog, fix printf format] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: bxcan: add support for single peripheral configurationDario Binacchi
Add support for bxCAN controller in single peripheral configuration: - primary bxCAN - dedicated Memory Access Controller unit - 512-byte SRAM memory - 14 filter banks Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/all/20230427204540.3126234-5-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: CAN_BXCAN should depend on ARCH_STM32Geert Uytterhoeven
The STMicroelectronics STM32 basic extended CAN Controller (bxCAN) is only present on STM32 SoCs. Hence drop the "|| OF" part from its dependency rule, to prevent asking the user about this driver when configuring a kernel without STM32 SoC support. Fixes: f00647d8127be4d3 ("can: bxcan: add support for ST bxCAN controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/40095112efd1b2214e4223109fd9f0c6d0158a2d.1680609318.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-05-15can: dev: fix missing CAN XL support in can_put_echo_skb()Oliver Hartkopp
can_put_echo_skb() checks for the enabled IFF_ECHO flag and the correct ETH_P type of the given skbuff. When implementing the CAN XL support the new check for ETH_P_CANXL has been forgotten. Fixes: fb08cba12b52 ("can: canxl: update CAN infrastructure for CAN XL frames") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230506184515.39241-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-04-04kvaser_usb: convert USB IDs to hexadecimal valuesOliver Hartkopp
USB IDs are usually represented in 16 bit hexadecimal values. To match the common representation in lsusb and for searching USB IDs in the internet convert the decimal values to lowercase hexadecimal. changes since v1: https://lore.kernel.org/all/20230327175344.4668-1-socketcan@hartkopp.net - drop the aligned block indentation (suggested by Jimmy) - use lowercase hex values (suggested by Alex) Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Acked-by: Jimmy Assarsson <extja@kvaser.com> Reviewed-by: Alexander Dahl <ada@thorsis.com> Link: https://lore.kernel.org/all/20230329090915.3127-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-04-04can: esd_usb: Add support for CAN_CTRLMODE_BERR_REPORTINGFrank Jungclaus
Announce that the driver supports CAN_CTRLMODE_BERR_REPORTING by means of priv->can.ctrlmode_supported. Until now berr reporting always has been active without taking care of the berr-reporting parameter given to an "ip link set ..." command. Additionally apply some changes to function esd_usb_rx_event(): - If berr reporting is off and it is also no state change, then immediately return. - Unconditionally (even in case of the above "immediate return") store tx- and rx-error counters, so directly use priv->bec.txerr and priv->bec.rxerr instead of intermediate variables. - Not directly related, but to better point out the linkage between a failed alloc_can_err_skb() and stats->rx_dropped++: Move the increment of the rx_dropped statistic counter (back) to directly behind the err_skb allocation. Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/all/20230330184446.2802135-1-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-04-04can: rcar_canfd: rcar_canfd_probe(): fix plain integer in transceivers[] initGeert Uytterhoeven
Fix the following compile warning with C=1: | drivers/net/can/rcar/rcar_canfd.c:1852:59: warning: Using plain integer as NULL pointer Fixes: a0340df7eca4f28e ("can: rcar_canfd: Add transceiver support") Reported-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20230328145658.7fdbc394@kernel.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/all/7f7b0dde0caa2d2977b4fb5b65b63036e75f5022.1680071972.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-03-28can: bxcan: add support for ST bxCAN controllerDario Binacchi
Add support for the basic extended CAN controller (bxCAN) found in many low- to middle-end STM32 SoCs. It supports the Basic Extended CAN protocol versions 2.0A and B with a maximum bit rate of 1 Mbit/s. The controller supports two channels (CAN1 as primary and CAN2 as secondary) and the driver can enable either or both of the channels. They share some of the required logic (e. g. clocks and filters), and that means you cannot use the secondary CAN without enabling some hardware resources managed by the primary CAN. Each channel has 3 transmit mailboxes, 2 receive FIFOs with 3 stages and 28 scalable filter banks. It also manages 4 dedicated interrupt vectors: - transmit interrupt - FIFO 0 receive interrupt - FIFO 1 receive interrupt - status change error interrupt Driver uses all 3 available mailboxes for transmission and FIFO 0 for reception. Rx filter rules are configured to the minimum. They accept all messages and assign filter 0 to CAN1 and filter 14 to CAN2 in identifier mask mode with 32 bits width. It enables and uses transmit, receive buffers for FIFO 0 and error and status change interrupts. Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20230328073328.3949796-6-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-03-24can: m_can: Keep interrupts enabled during peripheral readMarkus Schneider-Pargmann
Interrupts currently get disabled if the interrupt status shows new received data. Non-peripheral chips handle receiving in a worker thread, but peripheral chips are handling the receive process in the threaded interrupt routine itself without scheduling it for a different worker. So there is no need to disable interrupts for peripheral chips. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/all/20230315110546.2518305-6-msp@baylibre.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
generated by cgit (git 2.34.1) at 2025-07-18 15:08:15 +0000