kernel/linux.git/drivers/net/can/dev, branch v5.19

can: can-dev: remove obsolete CAN LED support

2022-05-19T20:15:51+00:00

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/20220518154527.29046-1-socketcan@hartkopp.net Suggested-by: Vincent Mailhol Signed-off-by: Oliver Hartkopp [mkl: remove led.h from MAINTAINERS] Signed-off-by: Marc Kleine-Budde

can: can-dev: move to netif_napi_add_weight()

2022-05-19T20:11:28+00:00

We want to remove the weight argument from the basic version of the netif_napi_add() call. Move all the callers in drivers/net/can that pass a custom weight (i.e. not NAPI_POLL_WEIGHT or 64) to the netif_napi_add_weight() API. Link: https://lore.kernel.org/all/20220517002345.1812104-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Marc Kleine-Budde

can: bittiming: can_calc_bittiming(): prefer small bit rate pre-scalers over larger ones

2022-04-19T15:12:05+00:00

The CiA (CAN in Automation) lists in their Newsletter 1/2018 in the "Recommendation for the CAN FD bit-timing" [1] article several recommendations, one of them is: | Recommendation 3: Choose BRPA and BRPD as low as possible [1] https://can-newsletter.org/uploads/media/raw/f6a36d1461371a2f86ef0011a513712c.pdf With the current bit timing algorithm Srinivas Neeli noticed that on the Xilinx Versal ACAP board the CAN data bit timing parameters are not calculated optimally. For most bit rates, the bit rate prescaler (BRP) is != 1, although it's possible to configure the requested with a bit rate with a prescaler of 1: | Data Bit timing parameters for xilinx_can_fd2i with 79.999999 MHz ref clock (cmd-line) using algo 'v4.8' | nominal real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error | 12000000 12 2 2 2 1 1 11428571 4.8% 75.0% 71.4% 4.8% | 10000000 25 1 1 1 1 2 9999999 0.0% 75.0% 75.0% 0.0% | 8000000 12 3 3 3 1 1 7999999 0.0% 75.0% 70.0% 6.7% | 5000000 50 1 1 1 1 4 4999999 0.0% 75.0% 75.0% 0.0% | 4000000 62 1 1 1 1 5 3999999 0.0% 75.0% 75.0% 0.0% | 2000000 125 1 1 1 1 10 1999999 0.0% 75.0% 75.0% 0.0% | 1000000 250 1 1 1 1 20 999999 0.0% 75.0% 75.0% 0.0% The bit timing parameter calculation algorithm iterates effectively from low to high BRP values. It selects a new best parameter set, if the sample point error of the current parameter set is equal or less to old best parameter set. If the given hardware constraints (clock rate and bit timing parameter constants) don't allow a sample point error of 0, the algorithm will first find a valid bit timing parameter set with a low BRP, but then will accept parameter sets with higher BRPs that have the same sample point error. This patch changes the algorithm to only accept a new parameter set, if the resulting sample point error is lower. This leads to the following data bit timing parameter for the Versal ACAP board: | Data Bit timing parameters for xilinx_can_fd2i with 79.999999 MHz ref clock (cmd-line) using algo 'can-next' | nominal real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error | 12000000 12 2 2 2 1 1 11428571 4.8% 75.0% 71.4% 4.8% | 10000000 12 2 3 2 1 1 9999999 0.0% 75.0% 75.0% 0.0% | 8000000 12 3 3 3 1 1 7999999 0.0% 75.0% 70.0% 6.7% | 5000000 12 5 6 4 1 1 4999999 0.0% 75.0% 75.0% 0.0% | 4000000 12 7 7 5 1 1 3999999 0.0% 75.0% 75.0% 0.0% | 2000000 12 14 15 10 1 1 1999999 0.0% 75.0% 75.0% 0.0% | 1000000 25 14 15 10 1 2 999999 0.0% 75.0% 75.0% 0.0% Note: Due to HW constraints a data bit rate of 1 MBit/s with BRP = 1 is not possible. Link: https://lore.kernel.org/all/20220318144913.873614-1-mkl@pengutronix.de Link: https://lore.kernel.org/all/20220113203004.jf2rqj2pirhgx72i@pengutronix.de Cc: Srinivas Neeli Signed-off-by: Marc Kleine-Budde

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

2022-04-19T14:58:04+00:00

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

can: Use netif_rx().

2022-03-06T11:05:31+00:00

Since commit baebdf48c3600 ("net: dev: Makes sure netif_rx() can be invoked in any context.") the function netif_rx() can be used in preemptible/thread context as well as in interrupt context. Use netif_rx(). Cc: Marc Kleine-Budde Cc: Oliver Hartkopp Cc: Wolfgang Grandegger Cc: linux-can@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior Acked-by: Oliver Hartkopp Acked-by: Marc Kleine-Budde Signed-off-by: David S. Miller

can: bittiming: mark function arguments and local variables as const

2022-02-24T07:26:03+00:00

This patch marks the arguments of some functions as well as some local variables as constant. Link: https://lore.kernel.org/all/20220124215642.3474154-7-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde

can: bittiming: can_validate_bitrate(): simplify bit rate checking

2022-02-24T07:26:03+00:00

This patch simplifies the validation of the fixed bit rates. If a supported bit rate is found, directly return 0. If no valid bit rate is found return -EINVAL; Link: https://lore.kernel.org/all/20220124215642.3474154-6-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde

can: netlink: report the CAN controller mode supported flags

2022-01-05T11:09:06+00:00

Currently, the CAN netlink interface provides no easy ways to check the capabilities of a given controller. The only method from the command line is to try each CAN_CTRLMODE_* individually to check whether the netlink interface returns an -EOPNOTSUPP error or not (alternatively, one may find it easier to directly check the source code of the driver instead...) This patch introduces a method for the user to check both the supported and the static capabilities. The proposed method introduces a new IFLA nest: IFLA_CAN_CTRLMODE_EXT which extends the current IFLA_CAN_CTRLMODE. This is done to guaranty a full forward and backward compatibility between the kernel and the user land applications. The IFLA_CAN_CTRLMODE_EXT nest contains one single entry: IFLA_CAN_CTRLMODE_SUPPORTED. Because this entry is only used in one direction: kernel to userland, no new struct nla_policy are introduced. Below table explains how IFLA_CAN_CTRLMODE_SUPPORTED (hereafter: "supported") and can_ctrlmode::flags (hereafter: "flags") allow us to identify both the supported and the static capabilities, when masked with any of the CAN_CTRLMODE_* bit flags: supported & flags & Controller capabilities CAN_CTRLMODE_* CAN_CTRLMODE_* ----------------------------------------------------------------------- false false Feature not supported (always disabled) false true Static feature (always enabled) true false Feature supported but disabled true true Feature supported and enabled Link: https://lore.kernel.org/all/20211213160226.56219-5-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde

can: dev: replace can_priv::ctrlmode_static by can_get_static_ctrlmode()

2022-01-05T11:09:05+00:00

The statically enabled features of a CAN controller can be retrieved using below formula: | u32 ctrlmode_static = priv->ctrlmode & ~priv->ctrlmode_supported; As such, there is no need to store this information. This patch remove the field ctrlmode_static of struct can_priv and provides, in replacement, the inline function can_get_static_ctrlmode() which returns the same value. Link: https://lore.kernel.org/all/20211213160226.56219-2-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde

can: do not increase rx_bytes statistics for RTR frames

2022-01-05T11:09:05+00:00

The actual payload length of the CAN Remote Transmission Request (RTR) frames is always 0, i.e. no payload is transmitted on the wire. However, those RTR frames still use the DLC to indicate the length of the requested frame. As such, net_device_stats::rx_bytes should not be increased for the RTR frames. This patch fixes all the CAN drivers. Link: https://lore.kernel.org/all/20211207121531.42941-5-mailhol.vincent@wanadoo.fr Cc: Marc Kleine-Budde Cc: Nicolas Ferre Cc: Alexandre Belloni Cc: Ludovic Desroches Cc: Chandrasekar Ramakrishnan Cc: Maxime Ripard Cc: Chen-Yu Tsai Cc: Jernej Skrabec Cc: Yasushi SHOJI Cc: Appana Durga Kedareswara rao Cc: Naga Sureshkumar Relli Cc: Michal Simek Cc: Stephane Grosjean Tested-by: Jimmy Assarsson # kvaser Signed-off-by: Vincent Mailhol Acked-by: Stefan Mätje # esd_usb2 Tested-by: Stefan Mätje # esd_usb2 Signed-off-by: Marc Kleine-Budde