can: c_can: Work around C_CAN RX wreckage
authorThomas Gleixner <tglx@linutronix.de>
Fri, 11 Apr 2014 08:13:17 +0000 (08:13 +0000)
committerMarc Kleine-Budde <mkl@pengutronix.de>
Thu, 24 Apr 2014 20:09:00 +0000 (22:09 +0200)
commitd61d09de023320b95a536eb4d31941e67002a93c
tree80b68aa639fd6ac670e933ac85e3b3fc94390167
parent2b9aecdce227e099349b73e3a074936d3c51f2a9
can: c_can: Work around C_CAN RX wreckage

Alexander reported that the new optimized handling of the RX fifo
causes random packet loss on Intel PCH C_CAN hardware.

After a few fruitless debugging sessions I got hold of a PCH (eg20t)
afflicted system. That machine does not have the CAN interface wired
up, but it was possible to reproduce the issue with the HW loopback
mode.

As Alexander observed correctly, clearing the NewDat flag along with
reading out the message buffer causes that issue on C_CAN, while D_CAN
handles that correctly.

Instead of restoring the original message buffer handling horror the
following workaround solves the issue:

    transfer buffer to IF without clearing the NewDat
    handle the message
    clear NewDat bit

That's similar to the original code but conditional for C_CAN.

I really wonder why all user manuals (C_CAN, Intel PCH and some more)
recommend to clear the NewDat bit right away. The knows it all Oracle
operated by Gurgle does not unearth any useful information either. I
simply cannot believe that we are the first to uncover that HW issue.

Reported-and-tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
drivers/net/can/c_can/c_can.c
drivers/net/can/c_can/c_can.h