mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-11 16:24:26 +08:00
d61d09de02
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>
|
||
|---|---|---|
| .. | ||
| c_can | ||
| cc770 | ||
| mscan | ||
| sja1000 | ||
| softing | ||
| usb | ||
| at91_can.c | ||
| bfin_can.c | ||
| dev.c | ||
| flexcan.c | ||
| grcan.c | ||
| janz-ican3.c | ||
| Kconfig | ||
| led.c | ||
| Makefile | ||
| mcp251x.c | ||
| pch_can.c | ||
| slcan.c | ||
| ti_hecc.c | ||
| vcan.c | ||