kernel/drivers/net/can, branch linux-4.16.y

can: dev: increase bus-off message severity

2018-06-20T19:01:39Z

[ Upstream commit 71c23a821c6bcacba71a094efe49ee689605906b ] 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 Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

can: hi311x: Work around TX complete interrupt erratum

2018-05-16T08:12:31Z

commit 32bee8f48fa048a3198109de50e51c092507ff52 upstream. When sending packets as fast as possible using "cangen -g 0 -i -x", the HI-3110 occasionally latches the interrupt pin high on completion of a packet, but doesn't set the TXCPLT bit in the INTF register. The INTF register contains 0x00 as if no interrupt has occurred. Even waiting for a few milliseconds after the interrupt doesn't help. Work around this apparent erratum by instead checking the TXMTY bit in the STATF register ("TX FIFO empty"). We know that we've queued up a packet for transmission if priv->tx_len is nonzero. If the TX FIFO is empty, transmission of that packet must have completed. Note that this is congruent with our handling of received packets, which likewise gleans from the STATF register whether a packet is waiting in the RX FIFO, instead of looking at the INTF register. Cc: Mathias Duckeck Cc: Akshay Bhat Cc: Casey Fitzpatrick Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Lukas Wunner Acked-by: Akshay Bhat Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: hi311x: Acquire SPI lock on ->do_get_berr_counter

2018-05-16T08:12:31Z

commit 5cec9425b41dcf834c3d48776900d6acb7e96f38 upstream. hi3110_get_berr_counter() may run concurrently to the rest of the driver but neglects to acquire the lock protecting access to the SPI device. As a result, it and the rest of the driver may clobber each other's tx and rx buffers. We became aware of this issue because transmission of packets with "cangen -g 0 -i -x" frequently hung. It turns out that agetty executes ->do_get_berr_counter every few seconds via the following call stack: CPU: 2 PID: 1605 Comm: agetty [<7f3f7500>] (hi3110_get_berr_counter [hi311x]) [<7f130204>] (can_fill_info [can_dev]) [<80693bc0>] (rtnl_fill_ifinfo) [<806949ec>] (rtnl_dump_ifinfo) [<806b4834>] (netlink_dump) [<806b4bc8>] (netlink_recvmsg) [<8065f180>] (sock_recvmsg) [<80660f90>] (___sys_recvmsg) [<80661e7c>] (__sys_recvmsg) [<80661ec0>] (SyS_recvmsg) [<80108b20>] (ret_fast_syscall+0x0/0x1c) agetty listens to netlink messages in order to update the login prompt when IP addresses change (if /etc/issue contains \4 or \6 escape codes): https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=e36deb6424e8 It's a useful feature, though it seems questionable that it causes CAN bit error statistics to be queried. Be that as it may, if hi3110_get_berr_counter() is invoked while a frame is sent by hi3110_hw_tx(), bogus SPI transfers like the following may occur: => 12 00 (hi3110_get_berr_counter() wanted to transmit EC 00 to query the transmit error counter, but the first byte was overwritten by hi3110_hw_tx_frame()) => EA 00 3E 80 01 FB (hi3110_hw_tx_frame() wanted to transmit a frame, but the first byte was overwritten by hi3110_get_berr_counter() because it wanted to query the receive error counter) This sequence hangs the transmission because the driver believes it has sent a frame and waits for the interrupt signaling completion, but in reality the chip has never sent away the frame since the commands it received were malformed. Fix by acquiring the SPI lock in hi3110_get_berr_counter(). I've scrutinized the entire driver for further unlocked SPI accesses but found no others. Cc: Mathias Duckeck Cc: Akshay Bhat Cc: Casey Fitzpatrick Cc: Stef Walter Cc: Karel Zak Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Lukas Wunner Reviewed-by: Akshay Bhat Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: kvaser_usb: Increase correct stats counter in kvaser_usb_rx_can_msg()

2018-05-16T08:12:30Z

commit 6ee00865ffe4e8c8ba4a68d26db53c7ec09bbb89 upstream. Increase rx_dropped, if alloc_can_skb() fails, not tx_dropped. Signed-off-by: Jimmy Assarsson Cc: linux-stable Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: flexcan: fix endianess detection

2018-05-16T08:12:30Z

commit 0e030a373df3b8792b8991740fc31fe0629c6e58 upstream. In commit 88462d2a7830 ("can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN controllers.") the following logic was implemented: if the dt property "big-endian" is given or the device is compatible to "fsl,p1010-flexcan": use big-endian mode; else use little-endian mode; This relies on commit d50f4630c2e1 ("arm: dts: Remove p1010-flexcan compatible from imx series dts") which was applied a few commits later. Without this commit (or an old device tree used for booting a new kernel) the flexcan devices on i.MX25, i.MX28, i.MX35 and i.MX53 match the 'the device is compatible to "fsl,p1010-flexcan"' test and so are switched erroneously to big endian mode. Instead of the check above put a quirk in devtype data and rely on of_match_device yielding the most compatible match Fixes: 88462d2a7830 ("can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN controllers.") Signed-off-by: Uwe Kleine-König Tested-by: Gavin Schenk Cc: linux-stable # >= v4.16 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman

can: cc770: Fix use after free in cc770_tx_interrupt()

2018-03-19T09:57:29Z

This fixes use after free introduced by the last cc770 patch. Signed-off-by: Andri Yngvason Fixes: 746201235b3f ("can: cc770: Fix queue stall & dropped RTR reply") Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: cc770: Fix queue stall & dropped RTR reply

2018-03-14T12:01:22Z

While waiting for the TX object to send an RTR, an external message with a matching id can overwrite the TX data. In this case we must call the rx routine and then try transmitting the message that was overwritten again. The queue was being stalled because the RX event did not generate an interrupt to wake up the queue again and the TX event did not happen because the TXRQST flag is reset by the chip when new data is received. According to the CC770 datasheet the id of a message object should not be changed while the MSGVAL bit is set. This has been fixed by resetting the MSGVAL bit before modifying the object in the transmit function and setting it after. It is not enough to set & reset CPUUPD. It is important to keep the MSGVAL bit reset while the message object is being modified. Otherwise, during RTR transmission, a frame with matching id could trigger an rx-interrupt, which would cause a race condition between the interrupt routine and the transmit function. Signed-off-by: Andri Yngvason Tested-by: Richard Weinberger Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: cc770: Fix stalls on rt-linux, remove redundant IRQ ack

2018-03-14T12:00:15Z

This has been reported to cause stalls on rt-linux. Suggested-by: Richard Weinberger Tested-by: Richard Weinberger Signed-off-by: Andri Yngvason Cc: linux-stable Signed-off-by: Marc Kleine-Budde

can: m_can: select pinctrl state in each suspend/resume function

2018-03-12T09:38:20Z

Make sure to apply the correct pin state in suspend/resume callbacks. Putting pins in sleep state saves power. Signed-off-by: Bich Hemon Signed-off-by: Marc Kleine-Budde

can: peak/pcie_fd: remove useless code when interface starts

2018-03-12T08:55:12Z

When an interface starts, the echo_skb array is empty and the network queue should be started only. This patch replaces useless code and locks when the internal RX_BARRIER message is received from the IP core, telling the driver that tx may start. Signed-off-by: Stephane Grosjean Cc: linux-stable Signed-off-by: Marc Kleine-Budde