can: cc770: Fix queue stall & dropped RTR reply
authorAndri Yngvason <andri.yngvason@marel.com>
Wed, 14 Mar 2018 11:52:57 +0000 (11:52 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 28 Mar 2018 16:39:23 +0000 (18:39 +0200)
commit5fdbcc3d6db6f17ec43ef200353208a3a9cf7234
treecbbff8dd04cdc309d73a924f2875c4cf6fdbd036
parent01a303d27a9c5fc80d7bdf2f2961e9ad14b608dc
can: cc770: Fix queue stall & dropped RTR reply

commit 746201235b3f876792099079f4c6fea941d76183 upstream.

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 <andri.yngvason@marel.com>
Tested-by: Richard Weinberger <richard@nod.at>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/net/can/cc770/cc770.c
drivers/net/can/cc770/cc770.h