kernel/linux.git/drivers/net/can/Kconfig, branch v6.7

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2023-10-13T00:07:34+00:00

Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: kernel/bpf/verifier.c 829955981c55 ("bpf: Fix verifier log for async callback return values") a923819fb2c5 ("bpf: Treat first argument as return value for bpf_throw") Signed-off-by: Jakub Kicinski

can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set

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

When adding the RISCV option I didn't gate it behind ARCH_SUNXI. As a result this option shows up with Allwinner support isn't enabled. Fix that by requiring ARCH_SUNXI to be set if RISCV is set. Fixes: 8abb95250ae6 ("can: sun4i_can: Add support for the Allwinner D1") Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/linux-sunxi/CAMuHMdV2m54UAH0X2dG7stEg=grFihrdsz4+o7=_DpBMhjTbkw@mail.gmail.com/ Signed-off-by: John Watts Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/all/20230905231342.2042759-2-contact@jookia.org Signed-off-by: Marc Kleine-Budde

can: at91_can: switch to rx-offload implementation

2023-10-05T19:47:45+00:00

The current at91_can driver uses NAPI to handle RX'ed CAN frames, the RX IRQ is disabled and a NAPI poll is scheduled. Then in at91_poll_rx() the RX'ed CAN frames are tried to read in order from the device. This approach has 2 drawbacks: - Under high system load it might take too long from the initial RX IRQ to the NAPI poll function to run. This causes RX buffer overflows. - The algorithm to read the CAN frames in order is not bullet proof and may fail under certain use cases/system loads. The rx-offload helper fixes these problems by reading the RX'ed CAN frames in the interrupt handler and adding it to a list sorted by RX timestamp. This list of RX'ed SKBs is then passed to the networking stack via NAPI. Convert the RX path to rx-offload, pass all CAN error frames with can_rx_offload_queue_timestamp(). Link: https://lore.kernel.org/all/20231005-at91_can-rx_offload-v2-27-9987d53600e0@pengutronix.de Signed-off-by: Marc Kleine-Budde

can: sun4i_can: Add support for the Allwinner D1

2023-07-28T06:47:18+00:00

The controllers present in the D1 are extremely similar to the R40 and require the same reset quirks, but An extra quirk is needed to support receiving packets. Signed-off-by: John Watts Link: https://lore.kernel.org/all/20230721221552.1973203-6-contact@jookia.org Signed-off-by: Marc Kleine-Budde

can: kvaser_pciefd: Add support for new Kvaser pciefd devices

2023-07-19T07:03:10+00:00

Add support for new Kvaser pciefd devices, based on SmartFusion2 SoC. Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20230622151153.294844-3-extja@kvaser.com [mkl: mark structs as static] Signed-off-by: Marc Kleine-Budde

can: kvaser_pciefd: Remove SPI flash parameter read functionality

2023-06-22T07:44:29+00:00

Remove SPI flash parameter read functionality, since it's only used for reading the interface CAN controller count. This information is already read from a register, making the information redundant. Signed-off-by: Jimmy Assarsson Reviewed-by: Vincent Mailhol Link: https://lore.kernel.org/all/20230529134248.752036-7-extja@kvaser.com Signed-off-by: Marc Kleine-Budde

can: CAN_BXCAN should depend on ARCH_STM32

2023-05-15T20:24:47+00:00

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 Reviewed-by: Simon Horman Link: https://lore.kernel.org/all/40095112efd1b2214e4223109fd9f0c6d0158a2d.1680609318.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde

can: bxcan: add support for ST bxCAN controller

2023-03-28T09:43:36+00:00

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 Reviewed-by: Vincent Mailhol Link: https://lore.kernel.org/all/20230328073328.3949796-6-dario.binacchi@amarulasolutions.com Signed-off-by: Marc Kleine-Budde

can: remove obsolete PCH CAN driver

2022-10-19T19:33:30+00:00

The PCH CAN driver is a driver for a Bosch C_CAN controller IP core which is attached to the system via PCI. This code has been introduced in 2011 by Oki Semiconductors developers to support the Intel Atom E6xx series I/O Hub (aka EG20T IOH PCH CAN). Since 2012 the driver only has been maintained by the kernel community. As there is a well maintained and continously tested C_CAN/D_CAN driver which also supports the PCI configuration from the PCH CAN EG20T setup this driver became obsolete. Cc: Jacob Kroon Cc: Marc Kleine-Budde Cc: Dario Binacchi Cc: Wolfgang Grandegger Signed-off-by: Oliver Hartkopp Link: https://lore.kernel.org/all/20220924174424.86541-1-socketcan@hartkopp.net Acked-by: Jacob Kroon Signed-off-by: Marc Kleine-Budde

can: slcan: use CAN network device driver API

2022-07-03T09:34:28+00:00

As suggested by commit [1], now the driver uses the functions and the data structures provided by the CAN network device driver interface. Currently the driver doesn't implement a way to set bitrate for SLCAN based devices via ip tool, so you'll have to do this by slcand or slcan_attach invocation through the -sX parameter: - slcan_attach -f -s6 -o /dev/ttyACM0 - slcand -f -s8 -o /dev/ttyUSB0 where -s6 in will set adapter's bitrate to 500 Kbit/s and -s8 to 1Mbit/s. See the table below for further CAN bitrates: - s0 -> 10 Kbit/s - s1 -> 20 Kbit/s - s2 -> 50 Kbit/s - s3 -> 100 Kbit/s - s4 -> 125 Kbit/s - s5 -> 250 Kbit/s - s6 -> 500 Kbit/s - s7 -> 800 Kbit/s - s8 -> 1000 Kbit/s In doing so, the struct can_priv::bittiming.bitrate of the driver is not set and since the open_candev() checks that the bitrate has been set, it must be a non-zero value, the bitrate is set to a fake value (-1U) before it is called. Using the rtnl_lock()/rtnl_unlock() functions has become a bit more tricky as the register_candev() function indirectly calls rtnl_lock() via register_netdev(). To avoid a deadlock it is therefore necessary to call rtnl_unlock() before calling register_candev(). The same goes for the unregister_candev() function. [1] commit 39549eef3587f ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20220628163137.413025-6-dario.binacchi@amarulasolutions.com Signed-off-by: Dario Binacchi Tested-by: Jeroen Hofstee Signed-off-by: Marc Kleine-Budde