kernel/linux.git/drivers/net/can/spi, branch v6.4

Merge tag 'linux-can-next-for-6.3-20230206' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

2023-02-07T14:54:09+00:00

Marc Kleine-Budde says: ==================== pull-request: can-next 2023-02-06 this is a pull request of 47 patches for net-next/master. The first two patch is by Oliver Hartkopp. One adds missing error checking to the CAN_GW protocol, the other adds a missing CAN address family check to the CAN ISO TP protocol. Thomas Kopp contributes a performance optimization to the mcp251xfd driver. The next 11 patches are by Geert Uytterhoeven and add support for R-Car V4H systems to the rcar_canfd driver. Stephane Grosjean and Lukas Magel contribute 8 patches to the peak_usb driver, which add support for configurable CAN channel ID. The last 17 patches are by me and target the CAN bit timing configuration. The bit timing is cleaned up, error messages are improved and forwarded to user space via NL_SET_ERR_MSG_FMT() instead of netdev_err(), and the SJW handling is updated, including the definition of a new default value that will benefit CAN-FD controllers, by increasing their oscillator tolerance. * tag 'linux-can-next-for-6.3-20230206' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (47 commits) can: bittiming: can_validate_bitrate(): report error via netlink can: bittiming: can_calc_bittiming(): convert from netdev_err() to NL_SET_ERR_MSG_FMT() can: bittiming: can_calc_bittiming(): clean up SJW handling can: bittiming: can_sjw_set_default(): use Phase Seg2 / 2 as default for SJW can: bittiming: can_sjw_check(): check that SJW is not longer than either Phase Buffer Segment can: bittiming: can_sjw_check(): report error via netlink and harmonize error value can: bittiming: can_fixup_bittiming(): report error via netlink and harmonize error value can: bittiming: factor out can_sjw_set_default() and can_sjw_check() can: bittiming: can_changelink() pass extack down callstack can: netlink: can_changelink(): convert from netdev_err() to NL_SET_ERR_MSG_FMT() can: netlink: can_validate(): validate sample point for CAN and CAN-FD can: dev: register_candev(): bail out if both fixed bit rates and bit timing constants are provided can: dev: register_candev(): ensure that bittiming const are valid can: bittiming: can_get_bittiming(): use direct return and remove unneeded else can: bittiming: can_fixup_bittiming(): set effective tq can: bittiming: can_fixup_bittiming(): use CAN_SYNC_SEG instead of 1 can: bittiming(): replace open coded variants of can_bit_time() can: peak_usb: Reorder include directives alphabetically can: peak_usb: align CAN channel ID format in log with sysfs attribute can: peak_usb: export PCAN CAN channel ID as sysfs device attribute ... ==================== Link: https://lore.kernel.org/r/20230206131620.2758724-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni

can: mcp251xfd: regmap: optimizing transfer size for CRC transfers size 1

2023-02-02T14:42:10+00:00

For CRC transfers with size 1 it is more efficient to use the write_safe command instead of the write_crc command. This saves the length byte on the SPI transfer. changes since v1: https://lore.kernel.org/all/20230127124258.2764-1-thomas.kopp@microchip.com - change logic to remove 1 level of indention Link: https://lore.kernel.org/all/20230202141811.2581795-1-mkl@pengutronix.de Signed-off-by: Thomas Kopp Signed-off-by: Marc Kleine-Budde

can: mcp251xfd: mcp251xfd_ring_set_ringparam(): assign missing tx_obj_num_coalesce_irq

2023-02-02T09:33:27+00:00

If the a new ring layout is set, the max coalesced frames for RX and TX are re-calculated, too. Add the missing assignment of the newly calculated TX max coalesced frames. Fixes: 656fc12ddaf8 ("can: mcp251xfd: add TX IRQ coalescing ethtool support") Link: https://lore.kernel.org/all/20230130154334.1578518-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde

can: dev: fix skb drop check

2022-11-07T13:00:27+00:00

In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") the priv->ctrlmode element is read even on virtual CAN interfaces that do not create the struct can_priv at startup. This out-of-bounds read may lead to CAN frame drops for virtual CAN interfaces like vcan and vxcan. This patch mainly reverts the original commit and adds a new helper for CAN interface drivers that provide the required information in struct can_priv. Fixes: a6d190f8c767 ("can: skb: drop tx skb if in listen only mode") Reported-by: Dariusz Stojaczyk Cc: Vincent Mailhol Cc: Max Staudt Signed-off-by: Oliver Hartkopp Acked-by: Vincent Mailhol Link: https://lore.kernel.org/all/20221102095431.36831-1-socketcan@hartkopp.net Cc: stable@vger.kernel.org # 6.0.x [mkl: patch pch_can, too] Signed-off-by: Marc Kleine-Budde

can: mcp251x: mcp251x_can_probe(): add missing unregister_candev() in error path

2022-10-25T07:13:14+00:00

In mcp251x_can_probe(), if mcp251x_gpio_setup() fails, it forgets to unregister the CAN device. Fix this by unregistering can device in mcp251x_can_probe(). Fixes: 2d52dabbef60 ("can: mcp251x: add GPIO support") Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/all/20221024090256.717236-1-dzm91@hust.edu.cn [mkl: adjust label] Signed-off-by: Marc Kleine-Budde

can: mcp251x: Fix race condition on receive interrupt

2022-08-09T19:40:22+00:00

The mcp251x driver uses both receiving mailboxes of the CAN controller chips. For retrieving the CAN frames from the controller via SPI, it checks once per interrupt which mailboxes have been filled and will retrieve the messages accordingly. This introduces a race condition, as another CAN frame can enter mailbox 1 while mailbox 0 is emptied. If now another CAN frame enters mailbox 0 until the interrupt handler is called next, mailbox 0 is emptied before mailbox 1, leading to out-of-order CAN frames in the network device. This is fixed by checking the interrupt flags once again after freeing mailbox 0, to correctly also empty mailbox 1 before leaving the handler. For reproducing the bug I created the following setup: - Two CAN devices, one Raspberry Pi with MCP2515, the other can be any. - Setup CAN to 1 MHz - Spam bursts of 5 CAN-messages with increasing CAN-ids - Continue sending the bursts while sleeping a second between the bursts - Check on the RPi whether the received messages have increasing CAN-ids - Without this patch, every burst of messages will contain a flipped pair v3: https://lore.kernel.org/all/20220804075914.67569-1-sebastian.wuerl@ororatech.com v2: https://lore.kernel.org/all/20220804064803.63157-1-sebastian.wuerl@ororatech.com v1: https://lore.kernel.org/all/20220803153300.58732-1-sebastian.wuerl@ororatech.com Fixes: bf66f3736a94 ("can: mcp251x: Move to threaded interrupts instead of workqueues.") Signed-off-by: Sebastian Würl Link: https://lore.kernel.org/all/20220804081411.68567-1-sebastian.wuerl@ororatech.com [mkl: reduce scope of intf1, eflag1] Signed-off-by: Marc Kleine-Budde

can: mcp251xfd: advertise timestamping capabilities and add ioctl support

2022-07-28T09:44:30+00:00

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 Link: https://lore.kernel.org/all/20220727101641.198847-10-mailhol.vincent@wanadoo.fr Signed-off-by: Marc Kleine-Budde

can: tree-wide: advertise software timestamping capabilities

2022-07-28T09:44:01+00:00

Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertised what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). This patch only targets the CAN drivers which *do not* support hardware timestamping. For each of those CAN drivers, implement the get_ts_info() using the generic ethtool_op_get_ts_info(). This way, userland can do: | $ ethtool --show-time-stamping canX to confirm the device timestamping capacities. N.B. the drivers which support hardware timestamping will be migrated in separate patches. Signed-off-by: Vincent Mailhol Link: https://lore.kernel.org/all/20220727101641.198847-6-mailhol.vincent@wanadoo.fr [mkl: mscan: add missing mscan_ethtool_ops] Signed-off-by: Marc Kleine-Budde

can: mcp251xfd: mcp251xfd_dump(): fix comment

2022-07-26T08:43:37+00:00

The driver uses only 1 TEF and 1 TX ring, but a variable number of RX rings. Fix comment accordingly. Fixes: e0ab3dd5f98f ("can: mcp251xfd: add dev coredump support") Link: https://lore.kernel.org/all/20220726084328.4042678-1-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde

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

2022-07-21T20:03:39+00:00

No conflicts. Signed-off-by: Jakub Kicinski