can: rockchip_canfd: add driver for Rockchip CAN-FD controller

Add driver for the Rockchip CAN-FD controller.

The IP core on the rk3568v2 SoC has 12 documented errata. Corrections
for these errata

can: rockchip_canfd: add driver for Rockchip CAN-FD controller

Add driver for the Rockchip CAN-FD controller.

The IP core on the rk3568v2 SoC has 12 documented errata. Corrections
for these errata will be added in the upcoming patches.

Since several workarounds are required for the TX path, only add the
base driver that only implements the RX path.

Although the RX path implements CAN-FD support, it's not activated in
ctrlmode_supported, as the IP core in the rk3568v2 has problems with
receiving or sending certain CAN-FD frames.

Tested-by: Alibek Omarov <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: Kconfig: remove obsolete help text for slcan

Commit cfcb4465e992 ("can: slcan: remove legacy infrastructure")
removed the 10-device limit. Update the Kconfig help text accordingly.

Signed-off

can: Kconfig: remove obsolete help text for slcan

Commit cfcb4465e992 ("can: slcan: remove legacy infrastructure")
removed the 10-device limit. Update the Kconfig help text accordingly.

Signed-off-by: Mans Rullgard <[email protected]>
Acked-by: Vincent Mailhol <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: kvaser_pciefd: Add support for Kvaser PCIe 8xCAN

Add support for new Kvaser pciefd device, PCIe 8xCAN, based on Xilinx FPGA.

Signed-off-by: Martin Jocic <[email protected]>
Link: https:/

can: kvaser_pciefd: Add support for Kvaser PCIe 8xCAN

Add support for new Kvaser pciefd device, PCIe 8xCAN, based on Xilinx FPGA.

Signed-off-by: Martin Jocic <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: kvaser_pciefd: Add support for Kvaser M.2 PCIe 4xCAN

Add support for new Kvaser pciefd device, M.2 PCIe 4xCAN, based on
Xilinx FPGA.

Signed-off-by: Jimmy Assarsson <[email protected]>
Link: htt

can: kvaser_pciefd: Add support for Kvaser M.2 PCIe 4xCAN

Add support for new Kvaser pciefd device, M.2 PCIe 4xCAN, based on
Xilinx FPGA.

Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: esd: add support for esd GmbH PCIe/402 CAN interface family

This patch adds support for the PCI based PCIe/402 CAN interface family
from esd GmbH that is available with various form factors
(ht

can: esd: add support for esd GmbH PCIe/402 CAN interface family

This patch adds support for the PCI based PCIe/402 CAN interface family
from esd GmbH that is available with various form factors
(https://esd.eu/en/products/402-series-can-interfaces).

All boards utilize a FPGA based CAN controller solution developed
by esd (esdACC). For more information on the esdACC see
https://esd.eu/en/products/esdacc.

This driver detects all available CAN interface board variants of
the family but atm. operates the CAN-FD capable devices in
Classic-CAN mode only! A later patch will introduce the CAN-FD
functionality in this driver.

Co-developed-by: Thomas Körper <[email protected]>
Signed-off-by: Thomas Körper <[email protected]>
Signed-off-by: Stefan Mätje <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set

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 tha

can: sun4i_can: Only show Kconfig if ARCH_SUNXI is set

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 <[email protected]>
Closes: https://lore.kernel.org/linux-sunxi/CAMuHMdV2m54UAH0X2dG7stEg=grFihrdsz4+o7=_DpBMhjTbkw@mail.gmail.com/
Signed-off-by: John Watts <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: at91_can: switch to rx-offload implementation

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 R

can: at91_can: switch to rx-offload implementation

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/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: sun4i_can: Add support for the Allwinner D1

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
receivi

can: sun4i_can: Add support for the Allwinner D1

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 <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: kvaser_pciefd: Add support for new Kvaser pciefd devices

Add support for new Kvaser pciefd devices, based on SmartFusion2 SoC.

Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://l

can: kvaser_pciefd: Add support for new Kvaser pciefd devices

Add support for new Kvaser pciefd devices, based on SmartFusion2 SoC.

Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
[mkl: mark structs as static]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: kvaser_pciefd: Remove SPI flash parameter read functionality

Remove SPI flash parameter read functionality, since it's only used for
reading the interface CAN controller count.
This information

can: kvaser_pciefd: Remove SPI flash parameter read functionality

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 <[email protected]>
Reviewed-by: Vincent Mailhol <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: CAN_BXCAN should depend on ARCH_STM32

The STMicroelectronics STM32 basic extended CAN Controller (bxCAN) is
only present on STM32 SoCs. Hence drop the "|| OF" part from its
dependency rule, to

can: CAN_BXCAN should depend on ARCH_STM32

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

show more ...

can: bxcan: add support for ST bxCAN controller

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 ver

can: bxcan: add support for ST bxCAN controller

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 <[email protected]>
Reviewed-by: Vincent Mailhol <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: remove obsolete PCH CAN driver

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 Semicond

can: remove obsolete PCH CAN driver

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 <[email protected]>
Cc: Marc Kleine-Budde <[email protected]>
Cc: Dario Binacchi <[email protected]>
Cc: Wolfgang Grandegger <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Acked-by: Jacob Kroon <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: slcan: use CAN network device driver API

As suggested by commit [1], now the driver uses the functions and the
data structures provided by the CAN network device driver interface.

Currently th

can: slcan: use CAN network device driver API

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/[email protected]
Signed-off-by: Dario Binacchi <[email protected]>
Tested-by: Jeroen Hofstee <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: can327: CAN/ldisc driver for ELM327 based OBD-II adapters

This is the can327 driver. It does a surprisingly good job at turning
ELM327 based OBD-II interfaces into cheap CAN interfaces for simp

can: can327: CAN/ldisc driver for ELM327 based OBD-II adapters

This is the can327 driver. It does a surprisingly good job at turning
ELM327 based OBD-II interfaces into cheap CAN interfaces for simple
homebrew projects.

Please see the included documentation for details and limitations:
Documentation/networking/device_drivers/can/can327.rst

Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Max Staudt <[email protected]>
Reviewed-by: Vincent Mailhol <[email protected]>
[mkl: minor coding style improvements]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

net: Kconfig: move the CAN device menu to the "Device Drivers" section

The devices are meant to be under the "Device Drivers" category of the
menuconfig. The CAN subsystem is currently one of the ra

net: Kconfig: move the CAN device menu to the "Device Drivers" section

The devices are meant to be under the "Device Drivers" category of the
menuconfig. The CAN subsystem is currently one of the rare exception
with all of its devices under the "Networking support" category.

The CAN_DEV menuentry gets moved to fix this discrepancy. The CAN menu
is added just before MCTP in order to be consistent with the current
order under the "Networking support" menu.

A dependency on CAN is added to CAN_DEV so that the CAN devices only
show up if the CAN subsystem is enabled.

Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Max Staudt <[email protected]>
Tested-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: Kconfig: add CONFIG_CAN_RX_OFFLOAD

Only a few drivers rely on the CAN rx offload framework (as of the
writing of this patch, only four: flexcan, m_can, mcp251xfd and
ti_hecc). Split it out of c

can: Kconfig: add CONFIG_CAN_RX_OFFLOAD

Only a few drivers rely on the CAN rx offload framework (as of the
writing of this patch, only four: flexcan, m_can, mcp251xfd and
ti_hecc). Split it out of can-dev and add a new config symbol:
CAN_RX_OFFLOAD.

The drivers relying on CAN rx offload are in different sub
folders. Make CAN_RX_OFFLOAD an hidden option and tag all the drivers
depending on that feature with "select CAN_RX_OFFLOAD" so that the
option gets automatically enabled if and only if one of those drivers
is chosen.

Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Geert Uytterhoeven <[email protected]>
Suggested-by: Jakub Kicinski <[email protected]>
Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Max Staudt <[email protected]>
Tested-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: bittiming: move bittiming calculation functions to calc_bittiming.c

The canonical way to select or deselect an object during compilation
is to use this pattern in the relevant Makefile:

bar-$(

can: bittiming: move bittiming calculation functions to calc_bittiming.c

The canonical way to select or deselect an object during compilation
is to use this pattern in the relevant Makefile:

bar-$(CONFIG_FOO) := foo.o

bittiming.c instead uses some #ifdef CONFIG_CAN_CALC_BITTIMG.

Create a new file named calc_bittiming.c with all the functions which
are conditionally compiled with CONFIG_CAN_CALC_BITTIMG and modify the
Makefile according to above pattern.

Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Max Staudt <[email protected]>
Tested-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV

In the next patches, the software/virtual drivers (slcan, v(x)can)
will depend on drivers/net/can/dev/skb.o.

This patch

can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEV

In the next patches, the software/virtual drivers (slcan, v(x)can)
will depend on drivers/net/can/dev/skb.o.

This patch changes the scope of the can-dev module to include the
above mentioned drivers.

To do so, we reuse the menu "CAN Device Drivers" and turn it into a
configmenu using the config symbol CAN_DEV (which we released in
previous patch). Also, add a description to this new CAN_DEV
menuconfig.

The symbol CAN_DEV now only triggers the build of skb.o. For this
reasons, all the macros from linux/module.h are deported from
drivers/net/can/dev/dev.c to drivers/net/can/dev/skb.c.

Finally, drivers/net/can/dev/Makefile is adjusted accordingly.

Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Max Staudt <[email protected]>
Tested-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK

In the next patches, the scope of the can-dev module will grow to
engloble the software/virtual drivers (slcan, v(x)can). To this
extent,

can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINK

In the next patches, the scope of the can-dev module will grow to
engloble the software/virtual drivers (slcan, v(x)can). To this
extent, release CAN_DEV by renaming it into CAN_NETLINK. The config
symbol CAN_DEV will be reused to cover this extended scope.

The rationale for the name CAN_NETLINK is that netlink is the
predominant feature added here.

The current description only mentions platform drivers despite the
fact that this symbol is also required by "normal" devices (e.g. USB
or PCI) which do not fall under the platform devices category. The
description is updated accordingly to fix this gap.

Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Max Staudt <[email protected]>
Tested-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: can-dev: remove obsolete CAN LED support

Since commit 30f3b42147ba6f ("can: mark led trigger as broken") the
CAN specific LED support was disabled and marked as BROKEN. As the
common LED suppor

can: can-dev: remove obsolete CAN LED support

Since commit 30f3b42147ba6f ("can: mark led trigger as broken") the
CAN specific LED support was disabled and marked as BROKEN. As the
common LED support with CONFIG_LEDS_TRIGGER_NETDEV should do this work
now the code can be removed as preparation for a CAN netdevice Kconfig
rework.

Link: https://lore.kernel.org/all/[email protected]
Suggested-by: Vincent Mailhol <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
[mkl: remove led.h from MAINTAINERS]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.

This driver adds support for the CTU CAN FD open-source IP core.
More documentation and core sources at project

can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.

This driver adds support for the CTU CAN FD open-source IP core.
More documentation and core sources at project page
(https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core).
The core integration to Xilinx Zynq system as platform driver
is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top).
Implementation on Intel FPGA based PCI Express board is available
from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd).

More about CAN bus related projects used and developed at CTU FEE at
https://canbus.pages.fel.cvut.cz/ .

Link: https://lore.kernel.org/all/1906e4941560ae2ce4b8d181131fd4963aa31611.1647904780.git.pisa@cmp.felk.cvut.cz
Signed-off-by: Martin Jerabek <[email protected]>
Signed-off-by: Ondrej Ille <[email protected]>
Signed-off-by: Pavel Pisa <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: flexcan: update Kconfig to enable coldfire

Update flexcan to support coldfire architecture.

Any new platform should use OF, but coldfire architecture is
actually not supporting devicetrees.

L

can: flexcan: update Kconfig to enable coldfire

Update flexcan to support coldfire architecture.

Any new platform should use OF, but coldfire architecture is
actually not supporting devicetrees.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Angelo Dureghello <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: grcan: add missing Kconfig dependency to HAS_IOMEM

On ARCHs without IOMEM support the grcan driver fails to link due to
missing iomem functionality. This patch adds the missing Kconfig
dependen

can: grcan: add missing Kconfig dependency to HAS_IOMEM

On ARCHs without IOMEM support the grcan driver fails to link due to
missing iomem functionality. This patch adds the missing Kconfig
dependency to HAS_IOMEM.

Link: https://lore.kernel.org/r/[email protected]
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

can: kvaser_pciefd: select CONFIG_CRC32

Without crc32, this driver fails to link:

arm-linux-gnueabi-ld: drivers/net/can/kvaser_pciefd.o: in function `kvaser_pciefd_probe':
kvaser_pciefd.c:(.text+0x

can: kvaser_pciefd: select CONFIG_CRC32

Without crc32, this driver fails to link:

arm-linux-gnueabi-ld: drivers/net/can/kvaser_pciefd.o: in function `kvaser_pciefd_probe':
kvaser_pciefd.c:(.text+0x2b0): undefined reference to `crc32_be'

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: David S. Miller <[email protected]>

show more ...