All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, linux-can@vger.kernel.org,
	kernel@pengutronix.de, Thomas Kopp <thomas.kopp@microchip.com>,
	stable@vger.kernel.org,
	Pavel Modilaynen <pavel.modilaynen@volvocars.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>
Subject: [PATCH net 11/15] can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround handling for mcp2517fd
Date: Mon,  4 Jul 2022 14:26:09 +0200	[thread overview]
Message-ID: <20220704122613.1551119-12-mkl@pengutronix.de> (raw)
In-Reply-To: <20220704122613.1551119-1-mkl@pengutronix.de>

From: Thomas Kopp <thomas.kopp@microchip.com>

The mcp251xfd compatible chips have an erratum ([1], [2]), where the
received CRC doesn't match the calculated CRC. In commit
c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work
around broken CRC on TBC register") the following workaround was
implementierend.

- If a CRC read error on the TBC register is detected and the first
  byte is 0x00 or 0x80, the most significant bit of the first byte is
  flipped and the CRC is calculated again.
- If the CRC now matches, the _original_ data is passed to the reader.
  For now we assume transferred data was OK.

Measurements on the mcp2517fd show that the workaround is applicable
not only of the lowest byte is 0x00 or 0x80, but also if 3 least
significant bits are set.

Update check on 1st data byte and workaround description accordingly.

[1] mcp2517fd: DS80000792C: "Incorrect CRC for certain READ_CRC commands"
[2] mcp2518fd: DS80000789C: "Incorrect CRC for certain READ_CRC commands"

Link: https://lore.kernel.org/all/DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com
Fixes: c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register")
Cc: stable@vger.kernel.org
Reported-by: Pavel Modilaynen <pavel.modilaynen@volvocars.com>
Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com>
[mkl: split into 2 patches, update patch description and documentation]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
 drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c
index 217510c12af5..211edd9ef0c9 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c
@@ -334,10 +334,12 @@ mcp251xfd_regmap_crc_read(void *context,
 		 * register. It increments once per SYS clock tick,
 		 * which is 20 or 40 MHz.
 		 *
-		 * Observation shows that if the lowest byte (which is
-		 * transferred first on the SPI bus) of that register
-		 * is 0x00 or 0x80 the calculated CRC doesn't always
-		 * match the transferred one.
+		 * Observation on the mcp2518fd shows that if the
+		 * lowest byte (which is transferred first on the SPI
+		 * bus) of that register is 0x00 or 0x80 the
+		 * calculated CRC doesn't always match the transferred
+		 * one. On the mcp2517fd this problem is not limited
+		 * to the first byte being 0x00 or 0x80.
 		 *
 		 * If the highest bit in the lowest byte is flipped
 		 * the transferred CRC matches the calculated one. We
@@ -346,7 +348,8 @@ mcp251xfd_regmap_crc_read(void *context,
 		 * correct.
 		 */
 		if (reg == MCP251XFD_REG_TBC &&
-		    (buf_rx->data[0] == 0x0 || buf_rx->data[0] == 0x80)) {
+		    ((buf_rx->data[0] & 0xf8) == 0x0 ||
+		     (buf_rx->data[0] & 0xf8) == 0x80)) {
 			/* Flip highest bit in lowest byte of le32 */
 			buf_rx->data[0] ^= 0x80;
 
-- 
2.35.1



  parent reply	other threads:[~2022-07-04 12:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-04 12:25 [PATCH net 0/15] pull-request: can 2022-07-04 Marc Kleine-Budde
2022-07-04 12:25 ` [PATCH net 01/15] can: bcm: use call_rcu() instead of costly synchronize_rcu() Marc Kleine-Budde
2022-07-05  3:30   ` patchwork-bot+netdevbpf
2022-07-04 12:26 ` [PATCH net 02/15] Revert "can: xilinx_can: Limit CANFD brp to 2" Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 03/15] can: rcar_canfd: Fix data transmission failed on R-Car V3U Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 04/15] can: gs_usb: gs_usb_open/close(): fix memory leak Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 05/15] can: grcan: grcan_probe(): remove extra of_node_get() Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 06/15] can: m_can: m_can_chip_config(): actually enable internal timestamping Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 07/15] can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bits Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 08/15] can: kvaser_usb: replace run-time checks with struct kvaser_usb_driver_info Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 09/15] can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 10/15] can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits Marc Kleine-Budde
2022-07-04 12:26 ` Marc Kleine-Budde [this message]
2022-07-04 12:26 ` [PATCH net 12/15] can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround broken CRC on TBC register Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 13/15] can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel() Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 14/15] can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read dev_id Marc Kleine-Budde
2022-07-04 12:26 ` [PATCH net 15/15] can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversion Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220704122613.1551119-12-mkl@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=davem@davemloft.net \
    --cc=kernel@pengutronix.de \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pavel.modilaynen@volvocars.com \
    --cc=stable@vger.kernel.org \
    --cc=thomas.kopp@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.