kernel/linux.git/drivers/net/can/dev.c, branch linux-4.20.y

can: dev: __can_get_echo_skb(): fix bogous check for non-existing skb by removing it

2019-01-31T07:15:43+00:00

commit 7b12c8189a3dc50638e7d53714c88007268d47ef upstream. This patch revert commit 7da11ba5c506 ("can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb") After introduction of this change we encountered following new error message on various i.MX plattforms (flexcan): | flexcan 53fc8000.can can0: __can_get_echo_skb: BUG! Trying to echo non | existing skb: can_priv::echo_skb[0] The introduction of the message was a mistake because priv->echo_skb[idx] = NULL is a perfectly valid in following case: If CAN_RAW_LOOPBACK is disabled (setsockopt) in applications, the pkt_type of the tx skb's given to can_put_echo_skb is set to PACKET_LOOPBACK. In this case can_put_echo_skb will not set priv->echo_skb[idx]. It is therefore kept NULL. As additional argument for revert: The order of check and usage of idx was changed. idx is used to access an array element before checking it's boundaries. Signed-off-by: Manfred Schlaegl Fixes: 7da11ba5c506 ("can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb") Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: dev: __can_get_echo_skb(): print error message, if trying to echo non existing skb

2018-11-09T16:20:46+00:00

Prior to echoing a successfully transmitted CAN frame (by calling can_get_echo_skb()), CAN drivers have to put the CAN frame (by calling can_put_echo_skb() in the transmit function). These put and get function take an index as parameter, which is used to identify the CAN frame. A driver calling can_get_echo_skb() with a index not pointing to a skb is a BUG, so add an appropriate error message. Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: dev: __can_get_echo_skb(): Don't crash the kernel if can_priv::echo_skb is accessed out of bounds

2018-11-09T16:20:43+00:00

If the "struct can_priv::echo_skb" is accessed out of bounds would lead to a kernel crash. Better print a sensible warning message instead and try to recover. Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: dev: __can_get_echo_skb(): replace struct can_frame by canfd_frame to access frame length

2018-11-09T16:20:40+00:00

This patch replaces the use of "struct can_frame::can_dlc" by "struct canfd_frame::len" to access the frame's length. As it is ensured that both structures have a compatible memory layout for this member this is no functional change. Futher, this compatibility is documented in a comment. Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: dev: can_get_echo_skb(): factor out non sending code to __can_get_echo_skb()

2018-11-09T16:20:34+00:00

This patch factors out all non sending parts of can_get_echo_skb() into a seperate function __can_get_echo_skb(), so that it can be re-used in an upcoming patch. Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: dev: enable multi-queue for SocketCAN devices

2018-07-27T08:40:16+00:00

The existing SocketCAN implementation provides alloc_candev() to allocate a CAN device using a single Tx and Rx queue. This can lead to priority inversion in case the single Tx queue is already full with low priority messages and a high priority message needs to be sent while the bus is fully loaded with medium priority messages. This problem can be solved by using the existing multi-queue support of the network subsytem. The commit makes it possible to use multi-queue in the CAN subsystem in the same way it is used in the Ethernet subsystem by adding an alloc_candev_mqs() call and accompanying macros. With this support a CAN device can use multi-queue qdisc (e.g. mqprio) to avoid the aforementioned priority inversion. The exisiting functionality of alloc_candev() is the same as before. CAN devices need to have prioritized multiple hardware queues or are able to abort waiting for arbitration to make sensible use of multi-queues. Signed-off-by: Zhu Yi Signed-off-by: Mark Jonas Reviewed-by: Heiko Schocher Signed-off-by: Marc Kleine-Budde

can: dev: use skb_put_zero to simplfy code

2018-07-27T08:40:16+00:00

use helper skb_put_zero to replace the pattern of skb_put() && memset() Signed-off-by: YueHaibing Signed-off-by: Marc Kleine-Budde

can: dev: increase bus-off message severity

2018-05-08T08:41:38+00:00

bus-off is usually caused by hardware malfunction or configuration error (baud rate mismatch) and causes a complete loss of communication. Increase the "bus-off" message's severity from netdev_dbg() to netdev_info() to make it visible to the user. A can interface going into bus-off is similar in severity to ethernet's "Link is Down" message, which is also printed at info level. It is debatable whether the the "restarted" message should also be changed to netdev_info() to make the interface state changes comprehensible from the kernel log. I have chosen to keep the "restarted" message at dbg for now as the "bus-off" message should be enough for the user to notice and investigate the problem. Signed-off-by: Jakob Unterwurzacher Cc: linux-can@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Marc Kleine-Budde

can: migrate documentation to restructured text

2018-01-26T09:46:44+00:00

The kernel documentation is now restructured text. Convert the SocketCAN documentation and include it in the toplevel kernel documentation. This patch doesn't do any content change. All references to can.txt in the code are converted to can.rst. Signed-off-by: Robert Schwebel Signed-off-by: Marc Kleine-Budde

can: dev: Add support for limiting configured bitrate

2018-01-16T14:11:32+00:00

Various CAN or CAN-FD IP may be able to run at a faster rate than what the transceiver the CAN node is connected to. This can lead to unexpected errors. However, CAN transceivers typically have fixed limitations and provide no means to discover these limitations at runtime. Therefore, add support for a can-transceiver node that can be reused by other CAN peripheral drivers to determine for both CAN and CAN-FD what the max bitrate that can be used. If the user tries to configure CAN to pass these maximum bitrates it will throw an error. Also add support for reading bitrate_max via the netlink interface. Reviewed-by: Suman Anna Signed-off-by: Franklin S Cooper Jr [nsekhar@ti.com: fix build error with !CONFIG_OF] Signed-off-by: Sekhar Nori Signed-off-by: Faiz Abbas Signed-off-by: Marc Kleine-Budde