aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/can/dev
AgeCommit message (Collapse)AuthorFilesLines
2024-05-07net: annotate writes on dev->mtu from ndo_change_mtu()Eric Dumazet1-1/+1
Simon reported that ndo_change_mtu() methods were never updated to use WRITE_ONCE(dev->mtu, new_mtu) as hinted in commit 501a90c94510 ("inet: protect against too small mtu values.") We read dev->mtu without holding RTNL in many places, with READ_ONCE() annotations. It is time to take care of ndo_change_mtu() methods to use corresponding WRITE_ONCE() Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Simon Horman <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Shannon Nelson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-02-14can: netlink: Fix TDCO calculation using the old data bittimingMaxime Jayat1-1/+1
The TDCO calculation was done using the currently applied data bittiming, instead of the newly computed data bittiming, which means that the TDCO had an invalid value unless setting the same data bittiming twice. Fixes: d99755f71a80 ("can: netlink: add interface for CAN-FD Transmitter Delay Compensation (TDC)") Signed-off-by: Maxime Jayat <[email protected]> Reviewed-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-10-11netdev: replace napi_reschedule with napi_scheduleChristian Marangi1-1/+1
Now that napi_schedule return a bool, we can drop napi_reschedule that does the same exact function. The function comes from a very old commit bfe13f54f502 ("ibm_emac: Convert to use napi_struct independent of struct net_device") and the purpose is actually deprecated in favour of different logic. Convert every user of napi_reschedule to napi_schedule. Signed-off-by: Christian Marangi <[email protected]> Acked-by: Jeff Johnson <[email protected]> # ath10k Acked-by: Nick Child <[email protected]> # ibm Acked-by: Marc Kleine-Budde <[email protected]> # for can/dev/rx-offload.c Reviewed-by: Eric Dumazet <[email protected]> Acked-by: Tariq Toukan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2023-10-05can: dev: add can_state_get_by_berr_counter() to return the CAN state based ↵Marc Kleine-Budde1-0/+22
on the current error counters Some CAN controllers do not have a register that contains the current CAN state, but only a register that contains the error counters. Introduce a new function can_state_get_by_berr_counter() that returns the current TX and RX state depending on the provided CAN bit error counters. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-10-05can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is ↵Marc Kleine-Budde1-1/+5
accessed out of bounds If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error. Fixes: a6e4bc530403 ("can: make the number of echo skb's configurable") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-5-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-10-05can: dev: can_restart(): move debug message and stats after successful restartMarc Kleine-Budde1-4/+4
Move the debug message "restarted" and the CAN restart stats_after_ the successful restart of the CAN device, because the restart may fail. While there update the error message from printing the error number to printing symbolic error names. Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-4-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol <[email protected]> [mkl: mention stats in subject and description, too] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-10-05can: dev: can_restart(): reverse logic to remove need for gotoMarc Kleine-Budde1-7/+4
Reverse the logic in the if statement and eliminate the need for a goto to simplify code readability. Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-3-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-10-05can: dev: can_restart(): fix race condition between controller restart and ↵Marc Kleine-Budde1-3/+4
netif_carrier_on() This race condition was discovered while updating the at91_can driver to use can_bus_off(). The following scenario describes how the converted at91_can driver would behave. When a CAN device goes into BUS-OFF state, the driver usually stops/resets the CAN device and calls can_bus_off(). This function sets the netif carrier to off, and (if configured by user space) schedules a delayed work that calls can_restart() to restart the CAN device. The can_restart() function first checks if the carrier is off and triggers an error message if the carrier is OK. Then it calls the driver's do_set_mode() function to restart the device, then it sets the netif carrier to on. There is a race window between these two calls. The at91 CAN controller (observed on the sama5d3, a single core 32 bit ARM CPU) has a hardware limitation. If the device goes into bus-off while sending a CAN frame, there is no way to abort the sending of this frame. After the controller is enabled again, another attempt is made to send it. If the bus is still faulty, the device immediately goes back to the bus-off state. The driver calls can_bus_off(), the netif carrier is switched off and another can_restart is scheduled. This occurs within the race window before the original can_restart() handler marks the netif carrier as OK. This would cause the 2nd can_restart() to be called with an OK netif carrier, resulting in an error message. The flow of the 1st can_restart() looks like this: can_restart() // bail out if netif_carrier is OK netif_carrier_ok(dev) priv->do_set_mode(dev, CAN_MODE_START) // enable CAN controller // sama5d3 restarts sending old message // CAN devices goes into BUS_OFF, triggers IRQ // IRQ handler start at91_irq() at91_irq_err_line() can_bus_off() netif_carrier_off() schedule_delayed_work() // IRQ handler end netif_carrier_on() The 2nd can_restart() will be called with an OK netif carrier and the error message will be printed. To close the race window, first set the netif carrier to on, then restart the controller. In case the restart fails with an error code, roll back the netif carrier to off. Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-2-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-10-05can: dev: can_restart(): don't crash kernel if carrier is OKMarc Kleine-Budde1-1/+2
During testing, I triggered a can_restart() with the netif carrier being OK [1]. The BUG_ON, which checks if the carrier is OK, results in a fatal kernel crash. This is neither helpful for debugging nor for a production system. [1] The root cause is a race condition in can_restart() which will be fixed in the next patch. Do not crash the kernel, issue an error message instead, and continue restarting the CAN device anyway. Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/all/20231005-can-dev-fix-can-restart-v2-1-91b5c1fd922c@pengutronix.de Reviewed-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-07-28can: rx-offload: add can_rx_offload_get_echo_skb_queue_tail()Marc Kleine-Budde1-1/+26
Add can_rx_offload_get_echo_skb_queue_tail(). This function addds the echo skb at the end of rx-offload the queue. This is intended for devices without timestamp support. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-07-28can: rx-offload: rename rx_offload_get_echo_skb() -> ↵Marc Kleine-Budde1-4/+5
can_rx_offload_get_echo_skb_queue_timestamp() Rename the rx_offload_get_echo_skb() function to can_rx_offload_get_echo_skb_queue_timestamp(), since it inserts the echo skb into the rx-offload queue sorted by timestamp. This is a preparation for adding can_rx_offload_get_echo_skb_queue_tail(), which adds the echo skb to the end of the queue. This is intended for devices that do not support timestamps. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-06-22can: length: refactor frame lengths definition to add size in bitsVincent Mailhol1-13/+2
Introduce a method to calculate the exact size in bits of a CAN(-FD) frame with or without dynamic bitstuffing. These are all the possible combinations taken into account: - Classical CAN or CAN-FD - Standard or Extended frame format - CAN-FD CRC17 or CRC21 - Include or not intermission Instead of doing several individual macro definitions, declare the can_frame_bits() function-like macro. To this extent, do a full refactoring of the length definitions. In addition add the can_frame_bytes(). This function-like macro replaces the existing macro: - CAN_FRAME_OVERHEAD_SFF: can_frame_bytes(false, false, 0) - CAN_FRAME_OVERHEAD_EFF: can_frame_bytes(false, true, 0) - CANFD_FRAME_OVERHEAD_SFF: can_frame_bytes(true, false, 0) - CANFD_FRAME_OVERHEAD_EFF: can_frame_bytes(true, true, 0) Function-like macros were chosen over inline functions because they can be used to initialize const struct fields. The different maximum frame lengths (maximum data length, including intermission) are as follow: Frame type bits bytes ------------------------------------------------------- Classic CAN SFF no bitstuffing 111 14 Classic CAN EFF no bitstuffing 131 17 Classic CAN SFF bitstuffing 135 17 Classic CAN EFF bitstuffing 160 20 CAN-FD SFF no bitstuffing 579 73 CAN-FD EFF no bitstuffing 598 75 CAN-FD SFF bitstuffing 712 89 CAN-FD EFF bitstuffing 736 92 The macro CAN_FRAME_LEN_MAX and CANFD_FRAME_LEN_MAX are kept as an alias to, respectively, can_frame_bytes(false, true, CAN_MAX_DLEN) and can_frame_bytes(true, true, CANFD_MAX_DLEN). In addition to the above: - Use ISO 11898-1:2015 definitions for the names of the CAN frame fields. - Include linux/bits.h for use of BITS_PER_BYTE. - Include linux/math.h for use of mult_frac() and DIV_ROUND_UP(). N.B: the use of DIV_ROUND_UP() is not new to this patch, but the include was previously omitted. - Add copyright 2023 for myself. Suggested-by: Thomas Kopp <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Reviewed-by: Thomas Kopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-06-22can: rx-offload: fix coding styleMarc Kleine-Budde1-1/+1
This patch aligns code to match open parenthesis. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-05-15can: dev: fix missing CAN XL support in can_put_echo_skb()Oliver Hartkopp1-1/+2
can_put_echo_skb() checks for the enabled IFF_ECHO flag and the correct ETH_P type of the given skbuff. When implementing the CAN XL support the new check for ETH_P_CANXL has been forgotten. Fixes: fb08cba12b52 ("can: canxl: update CAN infrastructure for CAN XL frames") Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_validate_bitrate(): report error via netlinkMarc Kleine-Budde1-0/+3
Report an error to user space via netlink if the requested bit rate is not supported by the device. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_calc_bittiming(): convert from netdev_err() to ↵Marc Kleine-Budde1-6/+7
NL_SET_ERR_MSG_FMT() Replace the netdev_err() by NL_SET_ERR_MSG_FMT() to better inform the user about the problem. While there, use %u to print unsigned values and improve error message a bit. In case of an error, return -EINVAL instead of -EDOM, this corresponds better to the actual meaning of the error value. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_calc_bittiming(): clean up SJW handlingMarc Kleine-Budde1-11/+6
In the current code, if the user configures a bitrate, a default SJW value of 1 is used. If the user configures both a bitrate and a SJW value, can_calc_bittiming() silently limits the SJW value to SJW max and TSEG2. We came to the conclusion that if the user provided an invalid SJW value, it's best to bail out and inform the user [1]. [1] https://lore.kernel.org/all/CAMZ6RqKqhmTgUZiwe5uqUjBDnhhC2iOjZ791+Y845btJYwVDKg@mail.gmail.com Further the ISO 11898-1:2015 standard mandates that "SJW shall be less than or equal to the minimum of these two items: Phase_Seg1 and Phase_Seg2." [2] The current code is missing that check. [2] https://lore.kernel.org/all/BL3PR11MB64844E3FC13C55433CDD0B3DFB449@BL3PR11MB6484.namprd11.prod.outlook.com The previous patches introduced 1) can_sjw_set_default() - sets a default value for SJW if unset 2) can_sjw_check() - implements a SJW check against SJW max, Phase Seg1 and Phase Seg2. In the error case this function reports the error to user space via netlink. Replace both the open-coded SJW default setting and the open-coded and insufficient checks of SJW with the helper functions can_sjw_set_default() and can_sjw_check(). Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/CAMZ6RqKqhmTgUZiwe5uqUjBDnhhC2iOjZ791+Y845btJYwVDKg@mail.gmail.com Link: https://lore.kernel.org/all/BL3PR11MB64844E3FC13C55433CDD0B3DFB449@BL3PR11MB6484.namprd11.prod.outlook.com Suggested-by: Thomas Kopp <[email protected]> Suggested-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_sjw_set_default(): use Phase Seg2 / 2 as default for SJWMarc Kleine-Budde1-2/+2
"The (Re-)Synchronization Jump Width (SJW) defines how far a resynchronization may move the Sample Point inside the limits defined by the Phase Buffer Segments to compensate for edge phase errors." [1] In other words, this means that the SJW parameter controls the tolerance of the CAN controller to frequency errors compared to other CAN controllers. If the user space does not provide an SJW parameter, the kernel chooses a default value of 1. This has proven to be a good default value for classic CAN controllers, but no longer for modern CAN-FD controllers. In the past there were CAN controllers like the sja1000 with a rather limited range of bit timing parameters. For the standard bit rates this results in the following bit timing parameters: | Bit timing parameters for sja1000 with 8.000000 MHz ref clock | _----+--------------=> tseg1: 1 … 16 | / / _---------=> tseg2: 1 … 8 | | | / _-----=> sjw: 1 … 4 | | | | / _-=> brp: 1 … 64 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1 | 1000000 125 2 3 2 1 1 1000000 0.0% 75.0% 75.0% 0.0% 0x00 0x14 | 800000 125 3 4 2 1 1 800000 0.0% 80.0% 80.0% 0.0% 0x00 0x16 | 666666 125 4 4 3 1 1 666666 0.0% 80.0% 75.0% 6.2% 0x00 0x27 | 500000 125 6 7 2 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00 0x1c | 250000 250 6 7 2 1 2 250000 0.0% 87.5% 87.5% 0.0% 0x01 0x1c | 125000 500 6 7 2 1 4 125000 0.0% 87.5% 87.5% 0.0% 0x03 0x1c | 100000 625 6 7 2 1 5 100000 0.0% 87.5% 87.5% 0.0% 0x04 0x1c | 83333 750 6 7 2 1 6 83333 0.0% 87.5% 87.5% 0.0% 0x05 0x1c | 50000 1250 6 7 2 1 10 50000 0.0% 87.5% 87.5% 0.0% 0x09 0x1c | 33333 1875 6 7 2 1 15 33333 0.0% 87.5% 87.5% 0.0% 0x0e 0x1c | 20000 3125 6 7 2 1 25 20000 0.0% 87.5% 87.5% 0.0% 0x18 0x1c | 10000 6250 6 7 2 1 50 10000 0.0% 87.5% 87.5% 0.0% 0x31 0x1c The attentive reader will notice that the SJW is 1 in most cases, while the Seg2 phase is 2. Both values are given in TQ units, which in turn is a duration in nanoseconds. For example the 500 kbit/s configuration: | nominal real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1 | 500000 125 6 7 2 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00 0x1c the TQ is 125ns, the Phase Seg2 is "2" (== 250ns), the SJW is "1" (== 125 ns). Looking at a more modern CAN controller like a mcp2518fd, it has wider bit timing registers. | Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock | _----+--------------=> tseg1: 2 … 256 | / / _---------=> tseg2: 1 … 128 | | | / _-----=> sjw: 1 … 128 | | | | / _-=> brp: 1 … 256 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error NBTCFG | 500000 25 34 35 10 1 1 500000 0.0% 87.5% 87.5% 0.0% 0x00440900 The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "1" (== 25ns). Since the kernel chooses a default SJW of 1 regardless of the TQ, this leads to a much smaller SJW and thus much smaller tolerances to frequency errors. To maintain the same oscillator tolerances on controllers with wide bit timing registers, select a default SJW value of Phase Seg2 / 2 unless Phase Seg 1 is less. This results in the following bit timing parameters: | Bit timing parameters for mcp251xfd with 40.000000 MHz ref clock | _----+--------------=> tseg1: 2 … 256 | / / _---------=> tseg2: 1 … 128 | | | / _-----=> sjw: 1 … 128 | | | | / _-=> brp: 1 … 256 (inc: 1) | | | | | / | nominal | | | | | real Bitrt nom real SampP | Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error NBTCFG | 500000 25 34 35 10 5 1 500000 0.0% 87.5% 87.5% 0.0% 0x00440904 The TQ is 25ns, the Phase Seg 2 is "10" (== 250ns), the SJW is "5" (== 125ns). Which is the same as on the sja1000 controller. [1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf Link: https://lore.kernel.org/all/[email protected] Cc: Mark Bath <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_sjw_check(): check that SJW is not longer than either ↵Marc Kleine-Budde1-0/+14
Phase Buffer Segment According to "The Configuration of the CAN Bit Timing" [1] the SJW "may not be longer than either Phase Buffer Segment". Check SJW against length of both Phase buffers. In case the SJW is greater, report an error via netlink to user space and bail out. [1] http://web.archive.org/http://www.oertel-halle.de/files/cia99paper.pdf Link: https://lore.kernel.org/all/[email protected] Suggested-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_sjw_check(): report error via netlink and harmonize ↵Marc Kleine-Budde1-2/+5
error value If the user space has supplied an invalid SJW value (greater than the maximum SJW value), report -EINVAL instead of -ERANGE, this better matches the actual meaning of the error value. Additionally report an error message via netlink to the user space. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_fixup_bittiming(): report error via netlink and ↵Marc Kleine-Budde1-7/+31
harmonize error value Check each bit timing parameter first individually against their limits and report a meaningful error message via netlink to the user space. In case of an error, return -EINVAL instead of -ERANGE, this corresponds better to the actual meaning of the error value. Link: https://lore.kernel.org/all/[email protected] Suggested-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: factor out can_sjw_set_default() and can_sjw_check()Marc Kleine-Budde1-4/+26
Factor out the functionality of assigning a SJW default value into can_sjw_set_default() and the checking the SJW limits into can_sjw_check(). This functions will be improved and called from a different function in the following patches. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_changelink() pass extack down callstackMarc Kleine-Budde3-9/+14
This is a preparation patch. In order to pass warning/error messages during netlink calls back to user space, pass the extack struct down the callstack of can_changelink(), the actual error messages will be added in the following ptaches. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: netlink: can_changelink(): convert from netdev_err() to ↵Marc Kleine-Budde1-4/+6
NL_SET_ERR_MSG_FMT() Since commit 51c352bdbcd2 ("netlink: add support for formatted extack messages") formatted extack messages are supported to inform the user space or warnings/errors during netlink calls. Replace the netdev_err() by NL_SET_ERR_MSG_FMT() to better inform the user about the problem. While there, use %u to print unsigned values and improve error message a bit. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: netlink: can_validate(): validate sample point for CAN and CAN-FDMarc Kleine-Budde1-1/+32
The sample point is a value in tenths of a percent. Meaningful values are between 0 and 1000. Invalid values are rejected and an error message is returned to user space via netlink. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: dev: register_candev(): bail out if both fixed bit rates and bit timing ↵Marc Kleine-Budde1-0/+5
constants are provided The CAN driver framework supports either fixed bit rates or bit timing constants. Bail out during driver registration if both are given. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: dev: register_candev(): ensure that bittiming const are validMarc Kleine-Budde1-0/+16
Implement the function can_bittiming_const_valid() to check the validity of the specified bit timing constant. Call this function from register_candev() to check the bit timing constants during the registration of the CAN interface. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_get_bittiming(): use direct return and remove unneeded elseMarc Kleine-Budde1-11/+7
Clean up the code flow a bit, don't assign err variable but directly return. Remove the unneeded else, too. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_fixup_bittiming(): set effective tqMarc Kleine-Budde1-0/+2
The can_fixup_bittiming() function is used to validate the user-supplied low-level bit timing parameters and calculate the bitrate prescaler (brp) from the requested time quanta (tq) and the CAN clock of the controller. can_fixup_bittiming() selects the best matching integer bit rate prescaler, which may result in a different time quantum than the value specified by the user. Calculate the resulting time quantum and assign it so that the user sees the effective time quantum. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming: can_fixup_bittiming(): use CAN_SYNC_SEG instead of 1Marc Kleine-Budde1-1/+1
Commit 1c47fa6b31c2 ("can: dev: add a helper function to calculate the duration of one bit") made the constant CAN_SYNC_SEG available in a header file. The magic number 1 in can_fixup_bittiming() represents the width of the sync segment, replace it by CAN_SYNC_SEG to make the code more readable. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2023-02-06can: bittiming(): replace open coded variants of can_bit_time()Marc Kleine-Budde2-5/+4
Commit 1c47fa6b31c2 ("can: dev: add a helper function to calculate the duration of one bit") added the helper function can_bit_time(). Replace open coded variants of can_bit_time() by the helper function. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-11-07can: dev: fix skb drop checkOliver Hartkopp1-9/+1
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 <[email protected]> Cc: Vincent Mailhol <[email protected]> Cc: Max Staudt <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Acked-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] # 6.0.x [mkl: patch pch_can, too] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-09-15can: canxl: update CAN infrastructure for CAN XL framesOliver Hartkopp1-18/+54
- add new ETH_P_CANXL ethernet protocol type - update skb checks for CAN XL - add alloc_canxl_skb() which now needs a data length parameter - introduce init_can_skb_reserve() to reduce code duplication Acked-by: Vincent Mailhol <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-09-15can: set CANFD_FDF flag in all CAN FD frame structuresOliver Hartkopp1-0/+11
To simplify the testing in user space all struct canfd_frame's provided by the CAN subsystem of the Linux kernel now have the CANFD_FDF flag set in canfd_frame::flags. NB: Handcrafted ETH_P_CANFD frames introduced via PF_PACKET socket might not set this bit correctly. During the check for sufficient headroom in PF_PACKET sk_buffs the uninitialized CAN sk_buff data structures are filled. In the case of a CAN FD frame the CANFD_FDF flag is set accordingly. As the CAN frame content is already zero initialized in alloc_canfd_skb() the obsolete initialization of cf->flags in the CTU CAN FD driver has been removed as it would overwrite the already set CANFD_FDF flag. Acked-by: Vincent Mailhol <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-09-15can: skb: add skb CAN frame data length helpersOliver Hartkopp2-9/+5
Add two helpers to retrieve the data length from CAN sk_buffs and prepare the length information to be a uint16 value for the CAN XL support. Acked-by: Vincent Mailhol <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-09-15can: skb: unify skb CAN frame identification helpersOliver Hartkopp1-8/+10
Replace open coded checks for sk_buffs containing Classical CAN and CAN FD frame structures as a preparation for CAN XL support. With the added length check the unintended processing of CAN XL frames having the CANXL_XLF bit set can be suppressed even when the skb->len fits to non CAN XL frames. The CAN_RAW socket needs a rework to use these helpers. Therefore the use of these helpers is postponed to the CAN_RAW CAN XL integration. The J1939 protocol gets a check for Classical CAN frames too. Acked-by: Vincent Mailhol <[email protected]> Signed-off-by: Oliver Hartkopp <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-09-05can: rx-offload: can_rx_offload_init_queue(): fix typoMarc Kleine-Budde1-1/+1
Fix typo "rounted" -> "rounded". Link: https://lore.kernel.org/all/[email protected] Fixes: d254586c3453 ("can: rx-offload: Add support for HW fifo based irq offloading") Reported-by: Uwe Kleine-König <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: dev: add generic function can_eth_ioctl_hwts()Vincent Mailhol1-0/+29
Tools based on libpcap (such as tcpdump) expect the SIOCSHWTSTAMP ioctl call to be supported. This is also specified in the kernel doc [1]. The purpose of this ioctl is to toggle the hardware timestamps. Currently, CAN devices which support hardware timestamping have those always activated. can_eth_ioctl_hwts() is a dumb function that will always succeed when requested to set tx_type to HWTSTAMP_TX_ON or rx_filter to HWTSTAMP_FILTER_ALL. [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 <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: dev: add generic function can_ethtool_op_get_ts_info_hwts()Vincent Mailhol1-0/+21
Add function can_ethtool_op_get_ts_info_hwts(). This function will be used by CAN devices with hardware TX/RX timestamping support to implement ethtool_ops::get_ts_info. This function does not offer support to activate/deactivate hardware timestamps at device level nor support the filter options (which is currently the case for all CAN devices with hardware timestamping support). The fact that hardware timestamp can not be deactivated at hardware level does not impact the userland. As long as the user do not set SO_TIMESTAMPING using a setsockopt() or ioctl(), the kernel will not emit TX timestamps (RX timestamps will still be reproted as it is the case currently). Drivers which need more fine grained control remains free to implement their own function, but we foresee that the generic function introduced here will be sufficient for the majority. Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: dev: add hardware TX timestampVincent Mailhol1-0/+6
Because of the loopback feature of socket CAN, hardware TX timestamps are nothing else than the hardware RX timespamp of the corresponding loopback packet. This patch simply reuses the hardware RX timestamp. The rationale to clone this timestamp value is that existing tools which rely of libpcap (such as tcpdump) expect support for both TX and RX hardware timestamps in order to activate the feature (i.e. no granular control to activate either of TX or RX hardware timestamps). Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-03can: netlink: dump bitrate 0 if can_priv::bittiming.bitrate is -1UDario Binacchi1-1/+2
Upcoming changes on slcan driver will require you to specify a bitrate of value -1 to prevent the open_candev() from failing but at the same time highlighting that it is a fake value. In this case the command `ip --details -s -s link show' would print 4294967295 as the bitrate value. The patch change this value in 0. Link: https://lore.kernel.org/all/[email protected] Suggested-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Dario Binacchi <[email protected]> Tested-by: Jeroen Hofstee <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-06-13can: netlink: allow configuring of fixed data bit rates without need for ↵Marc Kleine-Budde1-1/+2
do_set_data_bittiming callback This patch is similar to 7e193a42c37c ("can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback") but for data bit rates instead of bit rates. Usually CAN devices support configurable data bit rates. The limits are defined by struct can_priv::data_bittiming_const. Another way is to implement the struct can_priv::do_set_data_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::data_bittiming_const or struct can_priv::do_set_data_bittiming is implemented. In commit 431af779256c ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::data_bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_data_bittiming callback on devices with fixed data bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/[email protected] Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates") Acked-by: Max Staudt <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-06-11can: skb: drop tx skb if in listen only modeVincent Mailhol1-1/+8
Frames can be directly injected to a can driver via the packet socket. By doing so, it is possible to reach the net_device_ops::ndo_start_xmit function even if the driver is configured in listen only mode. Add a check in can_dropped_invalid_skb() to discard the skb if CAN_CTRLMODE_LISTENONLY is set. 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]>
2022-06-11can: skb: move can_dropped_invalid_skb() and can_skb_headroom_valid() to skb.cVincent Mailhol1-0/+58
The functions can_dropped_invalid_skb() and can_skb_headroom_valid() grew a lot over the years to a point which it does not make much sense to have them defined as static inline in header files. Move those two functions to the .c counterpart of skb.h. can_skb_headroom_valid()'s only caller being can_dropped_invalid_skb(), the declaration is removed from the header. Only can_dropped_invalid_skb() gets its symbol exported. While doing so, do a small cleanup: add brackets around the else block in can_dropped_invalid_skb(). Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Reported-by: kernel test robot <[email protected]> Acked-by: Max Staudt <[email protected]> Tested-by: Oliver Hartkopp <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-06-11can: Kconfig: add CONFIG_CAN_RX_OFFLOADVincent Mailhol1-1/+1
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]>
2022-06-11can: bittiming: move bittiming calculation functions to calc_bittiming.cVincent Mailhol3-197/+203
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]>
2022-06-11can: Kconfig: turn menu "CAN Device Drivers" into a menuconfig using CAN_DEVVincent Mailhol3-15/+17
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]>
2022-06-11can: Kconfig: rename config symbol CAN_DEV into CAN_NETLINKVincent Mailhol1-1/+1
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]>
2022-06-11can: netlink: allow configuring of fixed bit rates without need for ↵Marc Kleine-Budde1-1/+2
do_set_bittiming callback Usually CAN devices support configurable bit rates. The limits are defined by struct can_priv::bittiming_const. Another way is to implement the struct can_priv::do_set_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::bittiming_const or struct can_priv::do_set_bittiming is implemented. In commit 431af779256c ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_bittiming callback on devices with fixed bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/[email protected] Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates") Reported-by: Max Staudt <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-05-19can: can-dev: remove obsolete CAN LED supportOliver Hartkopp3-9/+0
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]>
Powered by cgit, Gruvboxed by Blaster4385.