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

can: bittiming: can_fixup_bittiming(): change type of tseg1 and alltseg to unsigned int

2021-11-18T18:16:19+00:00

[ Upstream commit e346290439609a8ac67122418ca2efbad8d0a7e7 ] All timing calculation is done with unsigned integers, so change type of tseg1 and alltseg to unsigned int, too. Link: https://lore.kernel.org/all/20211013130653.1513627-1-mkl@pengutronix.de Link: https://github.com/linux-can/can-utils/pull/314 Reported-by: Gary Bisson Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin

can: netlink: allow user to turn off unsupported features

2021-08-19T13:07:03+00:00

The sanity checks on the control modes will reject any request related to an unsupported features, even turning it off. Example on an interface which does not support CAN-FD: $ ip link set can0 type can bitrate 500000 fd off RTNETLINK answers: Operation not supported This patch lets such command go through (but requests to turn on an unsupported feature are, of course, still denied). Link: https://lore.kernel.org/r/20210815033248.98111-2-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde

can: dev: provide optional GPIO based termination support

2021-08-19T13:07:03+00:00

For CAN buses to work, a termination resistor has to be present at both ends of the bus. This resistor is usually 120 Ohms, other values may be required for special bus topologies. This patch adds support for a generic GPIO based CAN termination. The resistor value has to be specified via device tree, and it can only be attached to or detached from the bus. By default the termination is not active. Link: https://lore.kernel.org/r/20210818071232.20585-4-o.rempel@pengutronix.de Signed-off-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde

can: netlink: remove redundant check in can_validate()

2021-07-25T09:36:25+00:00

can_validate() does a first check: | if (is_can_fd) { | if (!data[IFLA_CAN_BITTIMING] || !data[IFLA_CAN_DATA_BITTIMING]) | return -EOPNOTSUPP; | } If that first if succeeds, we know that if is_can_fd is true then data[IFLA_CAN_BITTIMING is set. However, the next if switch does not leverage on above knowledge and redoes the check: | if (data[IFLA_CAN_DATA_BITTIMING]) { | if (!is_can_fd || !data[IFLA_CAN_BITTIMING]) | ^~~~~~~~~~~~~~~~~~~~~~~~ | return -EOPNOTSUPP; | } This patch removes that redundant check. Link: https://lore.kernel.org/r/20210603151550.140727-2-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde

can: netlink: clear data_bittiming if FD is turned off

2021-07-25T09:36:25+00:00

When the FD is turned off through the netlink interface, the data bit timing values still remain in data_bittiming and are displayed despite of the feature being disabled. Example: | $ ip link set can0 type can bitrate 500000 dbitrate 2000000 fd on | $ ip --details link show can0 | 1: can0: mtu 72 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10 | link/can promiscuity 0 minmtu 0 maxmtu 0 | can state STOPPED restart-ms 0 | bitrate 500000 sample-point 0.875 | tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1 | ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-inc 1 | dbitrate 2000000 dsample-point 0.750 | dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 | ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp-inc 1 | clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 | | $ ip link set can0 type can bitrate 500000 fd off | $ ip --details link show can0 | 1: can0: mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10 | link/can promiscuity 0 minmtu 0 maxmtu 0 | can state STOPPED restart-ms 0 | bitrate 500000 sample-point 0.875 | tq 12 prop-seg 69 phase-seg1 70 phase-seg2 20 sjw 1 | ES582.1/ES584.1: tseg1 2..256 tseg2 2..128 sjw 1..128 brp 1..512 brp-inc 1 | dbitrate 2000000 dsample-point 0.750 | dtq 12 dprop-seg 14 dphase-seg1 15 dphase-seg2 10 dsjw 1 | ES582.1/ES584.1: dtseg1 2..32 dtseg2 1..16 dsjw 1..8 dbrp 1..32 dbrp-inc 1 | clock 80000000 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 Remark: once FD is turned off, it is not possible to turn fd back on and reuse the previously input data bit timing values: | $ ip link set can0 type can bitrate 500000 fd on | RTNETLINK answers: Operation not supported This means that the user will need to re-configure the data bit timing in order to turn fd on again. Because old data bit timing values cannot be reused, this patch clears priv->data_bit timing whenever FD is turned off. This way, the data bit timing variables are not displayed anymore. Link: https://lore.kernel.org/r/20210618081904.141114-2-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde

can: rx-offload: can_rx_offload_threaded_irq_finish(): add new function to be called from threaded interrupt

2021-07-25T09:36:25+00:00

After reading all CAN frames from the controller in the IRQ handler and storing them into a skb_queue, the driver calls napi_schedule(). In the napi poll function the skb from the skb_queue are then pushed into the networking stack. However if napi_schedule() is called from a threaded IRQ handler this triggers the following error: | NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! To avoid this, create a new rx-offload function (can_rx_offload_threaded_irq_finish()) with a call to local_bh_disable()/local_bh_enable() around the napi_schedule() call. Convert all drivers that call can_rx_offload_irq_finish() from threaded IRQ context to can_rx_offload_threaded_irq_finish(). Link: https://lore.kernel.org/r/20210724204745.736053-4-mkl@pengutronix.de Suggested-by: Daniel Glöckner Tested-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde

can: rx-offload: can_rx_offload_irq_finish(): directly call napi_schedule()

2021-07-25T09:36:25+00:00

Instead of calling can_rx_offload_schedule() call napi_schedule() directly. As this was the last use of can_rx_offload_schedule() remove this helper function. Link: https://lore.kernel.org/r/20210724204745.736053-3-mkl@pengutronix.de Tested-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde

can: rx-offload: add skb queue for use during ISR

2021-07-25T09:36:25+00:00

Adding a skb to the skb_queue in rx-offload requires to take a lock. This commit avoids this by adding an unlocked skb queue that is appended at the end of the ISR. Having one lock at the end of the ISR should be OK as the HW is empty, not about to overflow. Link: https://lore.kernel.org/r/20210724204745.736053-2-mkl@pengutronix.de Tested-by: Oleksij Rempel Co-developed-by: Kurt Van Dijck Signed-off-by: Kurt Van Dijck Signed-off-by: Marc Kleine-Budde

can: skb: alloc_can{,fd}_skb(): set "cf" to NULL if skb allocation fails

2021-04-07T07:31:19+00:00

The handling of CAN bus errors typically consist of allocating a CAN error SKB using alloc_can_err_skb() followed by stats handling and filling the error details in the newly allocated CAN error SKB. Even if the allocation of the SKB fails the stats handling should not be skipped. The common pattern in CAN drivers is to allocate the skb and work on the struct can_frame pointer "cf", if it has been assigned by alloc_can_err_skb(). | skb = alloc_can_err_skb(priv->ndev, &cf); | | /* RX errors */ | if (bdiag1 & (MCP251XFD_REG_BDIAG1_DCRCERR | | MCP251XFD_REG_BDIAG1_NCRCERR)) { | netdev_dbg(priv->ndev, "CRC error\n"); | | stats->rx_errors++; | if (cf) | cf->data[3] |= CAN_ERR_PROT_LOC_CRC_SEQ; | } In case of an OOM alloc_can_err_skb() returns NULL, but doesn't set "cf" to NULL as well. For the above pattern to work the "cf" has to be initialized to NULL, which is easily forgotten. To solve this kind of problems, set "cf" to NULL if alloc_can_err_skb() returns NULL. Link: https://lore.kernel.org/r/20210402102245.1512583-1-mkl@pengutronix.de Suggested-by: Vincent MAILHOL Reviewed-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde

can: bittiming: add CAN_KBPS, CAN_MBPS and CAN_MHZ macros

2021-03-30T09:14:45+00:00

Add three macro to simplify the readability of big bit timing numbers: - CAN_KBPS: kilobits per second (one thousand) - CAN_MBPS: megabits per second (one million) - CAN_MHZ: megahertz per second (one million) Example: u32 bitrate_max = 8 * CAN_MBPS; struct can_clock clock = {.freq = 80 * CAN_MHZ}; instead of: u32 bitrate_max = 8000000; struct can_clock clock = {.freq = 80000000}; Apply the new macro to driver/net/can/dev/bittiming.c. Link: https://lore.kernel.org/r/20210306054040.76483-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde