can: mcp251xfd: __mcp251xfd_chip_set_mode(): increase poll timeout

The mcp251xfd controller needs an idle bus to enter 'Normal CAN 2.0
mode' or . The maximum length of a CAN frame is 736 bits (64 da

can: mcp251xfd: __mcp251xfd_chip_set_mode(): increase poll timeout

The mcp251xfd controller needs an idle bus to enter 'Normal CAN 2.0
mode' or . The maximum length of a CAN frame is 736 bits (64 data
bytes, CAN-FD, EFF mode, worst case bit stuffing and interframe
spacing). For low bit rates like 10 kbit/s the arbitrarily chosen
MCP251XFD_POLL_TIMEOUT_US of 1 ms is too small.

Otherwise during polling for the CAN controller to enter 'Normal CAN
2.0 mode' the timeout limit is exceeded and the configuration fails
with:

| $ ip link set dev can1 up type can bitrate 10000
| [ 731.911072] mcp251xfd spi2.1 can1: Controller failed to enter mode CAN 2.0 Mode (6) and stays in Configuration Mode (4) (con=0x068b0760, osc=0x00000468).
| [ 731.927192] mcp251xfd spi2.1 can1: CRC read error at address 0x0e0c (length=4, data=00 00 00 00, CRC=0x0000) retrying.
| [ 731.938101] A link change request failed with some changes committed already. Interface can1 may have been left with an inconsistent configuration, please check.
| RTNETLINK answers: Connection timed out

Make MCP251XFD_POLL_TIMEOUT_US timeout calculation dynamic. Use
maximum of 1ms and bit time of 1 full 64 data bytes CAN-FD frame in
EFF mode, worst case bit stuffing and interframe spacing at the
current bit rate.

For easier backporting define the macro MCP251XFD_FRAME_LEN_MAX_BITS
that holds the max frame length in bits, which is 736. This can be
replaced by can_frame_bits(true, true, true, true, CANFD_MAX_DLEN) in
a cleanup patch later.

Fixes: 55e5b97f003e8 ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
Signed-off-by: Fedor Ross <fedor.ross@ifm.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20230717-mcp251xfd-fix-increase-poll-timeout-v5-1-06600f34c684@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: advertise timestamping capabilities and add ioctl support

Currently, userland has no methods to query which timestamping
features are supported by the mcp251xfd driver (aside maybe o

can: mcp251xfd: advertise timestamping capabilities and add ioctl support

Currently, userland has no methods to query which timestamping
features are supported by the mcp251xfd driver (aside maybe of getting
RX messages and observe whether or not hardware timestamps stay at
zero).

The canonical way for a network driver to advertise what kind of
timestamping it supports is to implement
ethtool_ops::get_ts_info(). Here, we use the CAN specific
can_ethtool_op_get_ts_info_hwts() function to achieve this.

In addition, the driver currently does not support the hardware
timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and
SIOCGHWTSTAMP is "should". This patch fills up that gap by
implementing net_device_ops::ndo_eth_ioctl() using the CAN specific
function can_eth_ioctl_hwts().

[1] kernel doc Timestamping, section 3.1: "Hardware Timestamping
Implementation: Device Drivers"
Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers

Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Link: https://lore.kernel.org/all/20220727101641.198847-10-mailhol.vincent@wanadoo.fr
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: fix detection of mcp251863

In commit c6f2a617a0a8 ("can: mcp251xfd: add support for mcp251863")
support for the mcp251863 was added. However it was not taken into
account that the au

can: mcp251xfd: fix detection of mcp251863

In commit c6f2a617a0a8 ("can: mcp251xfd: add support for mcp251863")
support for the mcp251863 was added. However it was not taken into
account that the auto detection of the chip model cannot distinguish
between mcp2518fd and mcp251863 and would lead to a warning message if
the firmware specifies a mcp251863.

Fix auto detection: If a mcp2518fd compatible chip is found, keep the
mcp251863 if specified by firmware, use mcp2518fd instead.

Link: https://lore.kernel.org/all/20220706064835.1848864-1-mkl@pengutronix.de
Fixes: c6f2a617a0a8 ("can: mcp251xfd: add support for mcp251863")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: add CAN_ERR_CNT flag to notify availability of error counter

Add a dedicated flag in uapi/linux/can/error.h to notify the userland
that fields data[6] and data[7] of the CAN error frame were
re

can: add CAN_ERR_CNT flag to notify availability of error counter

Add a dedicated flag in uapi/linux/can/error.h to notify the userland
that fields data[6] and data[7] of the CAN error frame were
respectively populated with the tx and rx error counters.

For all driver tree-wide, set up this flags whenever needed.

Link: https://lore.kernel.org/all/20220719143550.3681-12-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversion

In mcp251xfd_register_get_dev_id() the device ID register is read with
handcrafted SPI transfers. As all registers, this re

can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversion

In mcp251xfd_register_get_dev_id() the device ID register is read with
handcrafted SPI transfers. As all registers, this register is in
little endian. Further it is not naturally aligned in struct
mcp251xfd_map_buf_nocrc::data. However after the transfer the register
content is converted from big endian to CPU endianness not taking care
of being unaligned.

Fix the conversion by converting from little endian to CPU endianness
taking the unaligned source into account.

Side note: So far the register content is 0x0 on all mcp251xfd
compatible chips, and is only used for an informative printk.

Link: https://lore.kernel.org/all/20220627092859.809042-1-mkl@pengutronix.de
Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
Reviewed-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read dev_id

The device ID register is 32 bits wide. The driver uses incorrectly
the size of a pointer to a u32 to calculate the

can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read dev_id

The device ID register is 32 bits wide. The driver uses incorrectly
the size of a pointer to a u32 to calculate the length of the SPI
transfer. This results in a read of 2 registers on 64 bit platforms.
This is no problem on the Linux side, as the RX buffer of the SPI
transfer is large enough. In the mpc251xfd chip this results in the
read of an undocumented register. So far no problems were observed.

Fix the length of the SPI transfer to read the device ID register
only.

Link: https://lore.kernel.org/all/20220616094914.244440-1-mkl@pengutronix.de
Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel()

In commit 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing
support") software based TX coalescing was added to the driver. The
key

can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel()

In commit 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing
support") software based TX coalescing was added to the driver. The
key idea is to keep the TX complete IRQ disabled for some time after
processing it and re-enable later by a hrtimer. When bringing the
interface down, this timer has to be stopped.

Add the missing hrtimer_cancel() of the tx_irq_time hrtimer to
mcp251xfd_stop().

Link: https://lore.kernel.org/all/20220620143942.891811-1-mkl@pengutronix.de
Fixes: 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing support")
Cc: stable@vger.kernel.org # v5.18
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: add support for mcp251863

The MCP251863 device is a CAN-FD controller (MCP2518FD) with an
integrated transceiver (ATA6563). This patch add support for the new
device.

Link: https://

can: mcp251xfd: add support for mcp251863

The MCP251863 device is a CAN-FD controller (MCP2518FD) with an
integrated transceiver (ATA6563). This patch add support for the new
device.

Link: https://lore.kernel.org/all/20220419072805.2840340-3-mkl@pengutronix.de
Cc: Thomas Kopp <thomas.kopp@microchip.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: rx-offload: rename can_rx_offload_queue_sorted() -> can_rx_offload_queue_timestamp()

This patch renames the function can_rx_offload_queue_sorted() to
can_rx_offload_queue_timestamp(). This bett

can: rx-offload: rename can_rx_offload_queue_sorted() -> can_rx_offload_queue_timestamp()

This patch renames the function can_rx_offload_queue_sorted() to
can_rx_offload_queue_timestamp(). This better describes what the
function does, it adds a newly RX'ed skb to the sorted queue by its
timestamp.

Link: https://lore.kernel.org/all/20220417194327.2699059-1-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix return of error value

Clang static analysis reports this issue:

| mcp251xfd-core.c:1813:7: warning: The left operand
| of '&' is a garbage val

can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix return of error value

Clang static analysis reports this issue:

| mcp251xfd-core.c:1813:7: warning: The left operand
| of '&' is a garbage value
| FIELD_GET(MCP251XFD_REG_DEVID_ID_MASK, dev_id),
| ^ ~~~~~~

dev_id is set in a successful call to mcp251xfd_register_get_dev_id().
Though the status of calls made by mcp251xfd_register_get_dev_id() are
checked and handled, their status' are not returned. So return err.

Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN")
Link: https://lore.kernel.org/all/20220319153128.2164120-1-trix@redhat.com
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: add RX IRQ coalescing support

This patch adds RX IRQ coalescing support to the driver.

The mcp251xfd chip doesn't support proper hardware based coalescing,
so this patch tries to im

can: mcp251xfd: add RX IRQ coalescing support

This patch adds RX IRQ coalescing support to the driver.

The mcp251xfd chip doesn't support proper hardware based coalescing,
so this patch tries to implemented it in software. The RX-FIFO offers
a "FIFO not empty" interrupt, which is used if no coalescing is
active.

With activated RX IRQ coalescing the "FIFO not empty" interrupt is
disabled in the RX IRQ handler and the "FIFO half full" or "FIFO full
interrupt" (depending on RX max coalesced frames IRQ) is used instead.
To avoid RX CAN frame starvation a hrtimer is setup with RX coalesce
usecs IRQ,on timer expiration the "FIFO not empty" is enabled again.

Support for ethtool configuration is added in the next patch.

Link: https://lore.kernel.org/20220313083640.501791-9-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: ethtool: add support

This patch adds basic ethtool support (to query the current and
maximum ring parameters) to the driver.

Link: https://lore.kernel.org/20220313083640.501791-5-mk

can: mcp251xfd: ethtool: add support

This patch adds basic ethtool support (to query the current and
maximum ring parameters) to the driver.

Link: https://lore.kernel.org/20220313083640.501791-5-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: prepare for multiple RX-FIFOs

This patch prepares the driver to use more than one RX-FIFO. Having a
bigger RX buffer is beneficial in high load situations, where the
system temporari

can: mcp251xfd: prepare for multiple RX-FIFOs

This patch prepares the driver to use more than one RX-FIFO. Having a
bigger RX buffer is beneficial in high load situations, where the
system temporarily cannot keep up reading CAN frames from the chip.
Using a bigger RX buffer also allows to implement RX IRQ coalescing,
which will be added in a later patch series.

If using more than 1 RX-FIFO the driver has to figure out, which FIFOs
have RX'ed CAN frames pending. This is indicated by a set bit in the
RXIF register, which is positioned directly after the interrupt status
register INT. If more than 1 RX-FIFO is used, the driver reads both
registers in 1 transfer.

The mcp251xfd_handle_rxif() function iterates over all RX rings and
reads out the RX'ed CAN frames for for all pending FIFOs. To keep the
logic for the 1 RX-FIFO only case in mcp251xfd_handle_rxif() simple,
the driver marks that FIFO pending in mcp251xfd_ring_init().

The chip has a dedicated RX interrupt line to signal pending RX'ed
frames. If connected to an input GPIO and the driver will skip the
initial read of the interrupt status register (INT) and directly read
the pending RX'ed frames if the line is active. The driver assumes the
1st RX-FIFO pending (a read of the RXIF register would re-introduce
the skipped initial read of the INT register). Any other pending
RX-FIFO will be served in the main interrupt handler.

Link: https://lore.kernel.org/all/20220217103826.2299157-8-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: ring: mcp251xfd_ring_init(): checked RAM usage of ring setup

With this patch the usage of the on-chip RAM is checked. In the
current driver the FIFO setup is fixed and always fits in

can: mcp251xfd: ring: mcp251xfd_ring_init(): checked RAM usage of ring setup

With this patch the usage of the on-chip RAM is checked. In the
current driver the FIFO setup is fixed and always fits into the RAM.

With an upcoming patch series the ring and FIFO setup will be more
dynamic. Although using more RAM than available should not happen, but
add this safety check, just in case.

Link: https://lore.kernel.org/all/20220217103826.2299157-6-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: add support for internal PLL

The PLL is enabled if the configured clock is less than or equal to 10 times
the max clock frequency.

The device will operate with two different SPI spe

can: mcp251xfd: add support for internal PLL

The PLL is enabled if the configured clock is less than or equal to 10 times
the max clock frequency.

The device will operate with two different SPI speeds. A slow speed determined
by the clock without the PLL enabled, and a fast speed derived from the
frequency with the PLL enabled.

Link: https://lore.kernel.org/all/20220207131047.282110-16-mkl@pengutronix.de
Link: https://lore.kernel.org/all/20201015124401.2766-3-mas@csselectronics.com
Co-developed-by: Magnus Aagaard Sørensen <mas@csselectronics.com>
Signed-off-by: Magnus Aagaard Sørensen <mas@csselectronics.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_register(): prepare to activate PLL after softreset

If the PLL is needed it must be switched on after chip reset. This
patch adds the required call to mcp251xfd_register().

can: mcp251xfd: mcp251xfd_register(): prepare to activate PLL after softreset

If the PLL is needed it must be switched on after chip reset. This
patch adds the required call to mcp251xfd_register().

Link: https://lore.kernel.org/all/20220207131047.282110-15-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_clock_init(): prepare for PLL support, wait for OSC ready

This patch prepares the mcp251xfd_chip_clock_init() function for PLL
support.

If the PLL is needed is must b

can: mcp251xfd: mcp251xfd_chip_clock_init(): prepare for PLL support, wait for OSC ready

This patch prepares the mcp251xfd_chip_clock_init() function for PLL
support.

If the PLL is needed is must be switched on after chip reset. This
should be done in the mcp251xfd_chip_clock_init() function. Prepare
this function to wait for the OSC and PLL to be ready.

Link: https://lore.kernel.org/all/20220207131047.282110-14-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: __mcp251xfd_chip_set_mode(): prepare for PLL support: improve error handling and diagnostics

This patch prepares the __mcp251xfd_chip_set_mode() function for PLL
support by adding mo

can: mcp251xfd: __mcp251xfd_chip_set_mode(): prepare for PLL support: improve error handling and diagnostics

This patch prepares the __mcp251xfd_chip_set_mode() function for PLL
support by adding more error checks and diagnostics.

Link: https://lore.kernel.org/all/20220207131047.282110-13-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_wake(): renamed from mcp251xfd_chip_clock_enable()

This patch renames mcp251xfd_chip_clock_enable() into mcp251xfd_chip_wake() as
this function actually wakes the chip

can: mcp251xfd: mcp251xfd_chip_wake(): renamed from mcp251xfd_chip_clock_enable()

This patch renames mcp251xfd_chip_clock_enable() into mcp251xfd_chip_wake() as
this function actually wakes the chip. Additionally the documentation is
adopted.

Link: https://lore.kernel.org/all/20220207131047.282110-12-mkl@pengutronix.de
Co-developed-by: Magnus Aagaard Sørensen <mas@csselectronics.com>
Signed-off-by: Magnus Aagaard Sørensen <mas@csselectronics.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_timestamp_init(): factor out into separate function

This patch factors out the timestamp initialization from the clock
initialization.

This is a preparation patch for

can: mcp251xfd: mcp251xfd_chip_timestamp_init(): factor out into separate function

This patch factors out the timestamp initialization from the clock
initialization.

This is a preparation patch for the PLL support, where clock and
timestamp init must be done separately.

Link: https://lore.kernel.org/all/20220207131047.282110-11-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_softreset_check(): wait for OSC ready before accessing chip

This patch changes the order of reading the Mode and Oscillator Ready
bits.

Instead of reading the Mode of

can: mcp251xfd: mcp251xfd_chip_softreset_check(): wait for OSC ready before accessing chip

This patch changes the order of reading the Mode and Oscillator Ready
bits.

Instead of reading the Mode of the chip directly after reset, first
wait for the oscillator to get ready and the chip to fully start up.
Read the Mode after this.

Link: https://lore.kernel.org/all/20220207131047.282110-10-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): prepare for PLL support

The function mcp251xfd_chip_wait_for_osc_ready() polls the Oscillator
Control Register for the oscillator to get ready. B

can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): prepare for PLL support

The function mcp251xfd_chip_wait_for_osc_ready() polls the Oscillator
Control Register for the oscillator to get ready. By passing the
appropriate parameters (osc_reference and osc_mask) it can also poll
for PLL ready.

This patch adjusts the error message if the Oscillator and/or PLL fail
to get ready.

Link: https://lore.kernel.org/all/20220207131047.282110-9-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): improve chip detection and error handling

The function mcp251xfd_chip_wait_for_osc_ready() polls the Oscillator
Control Register for the oscillat

can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): improve chip detection and error handling

The function mcp251xfd_chip_wait_for_osc_ready() polls the Oscillator
Control Register for the oscillator to get ready.

This is the first register the driver reads from. Reading implausible
values (all bits set or unset) can be caused by the chip starting up
after power on, waking up after sleep, or by the chip not being preset
at all. Add check for implausible register content
mcp251xfd_reg_invalid() to the regmap_read_poll_timeout() loop.

In case of a regmap_read_poll_timeout() returns a fatal error (and not
a timeout), forward it to the caller.

As mcp251xfd_chip_wait_for_osc_ready() will be called after the probe
function has finished, (currently during ifup), move error message
about failed chip detection from there into the probe function.

Link: https://lore.kernel.org/all/20220207131047.282110-8-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): factor out into separate function

This patch factors out mcp251xfd_chip_wait_for_osc_ready() into a
separate function, it will be used in several

can: mcp251xfd: mcp251xfd_chip_wait_for_osc_ready(): factor out into separate function

This patch factors out mcp251xfd_chip_wait_for_osc_ready() into a
separate function, it will be used in several places in the next
patches.

Link: https://lore.kernel.org/all/20220207131047.282110-7-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...

can: mcp251xfd: mcp251xfd_chip_stop(): convert to a void function

The mcp251xfd_chip_stop() function tries the best to stop the chip and
put it into sleep mode. It continues, even if some intermedia

can: mcp251xfd: mcp251xfd_chip_stop(): convert to a void function

The mcp251xfd_chip_stop() function tries the best to stop the chip and
put it into sleep mode. It continues, even if some intermediate steps
fail. As none of the callers use the return value, let this function
return void.

Link: https://lore.kernel.org/all/20220207131047.282110-6-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

show more ...