From d61d09de023320b95a536eb4d31941e67002a93c Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Fri, 11 Apr 2014 08:13:17 +0000 Subject: 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 Signed-off-by: Thomas Gleixner Signed-off-by: Marc Kleine-Budde --- drivers/net/can/c_can/c_can.h | 1 + 1 file changed, 1 insertion(+) (limited to 'drivers/net/can/c_can/c_can.h') diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h index cd91960ce92c..792944c74b94 100644 --- a/drivers/net/can/c_can/c_can.h +++ b/drivers/net/can/c_can/c_can.h @@ -198,6 +198,7 @@ struct c_can_priv { u32 __iomem *raminit_ctrlreg; unsigned int instance; void (*raminit) (const struct c_can_priv *priv, bool enable); + u32 comm_rcv_high; u32 rxmasked; u32 dlc[C_CAN_MSG_OBJ_TX_NUM]; }; -- cgit