summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorAndri Yngvason <andri.yngvason@marel.com>2018-03-14 11:52:57 +0000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-03-28 18:40:15 +0200
commit2347221a6174ece34e161545c76f6f29991b5c83 (patch)
tree8754d499f78cb59c944d2cc65bf8b5f8b840a9fa /tools/perf/scripts/python
parente41a696498abaf4001ca42ce1dbc585b8ecdd96a (diff)
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>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions