All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Thomas.Kopp@microchip.com>
To: <pavel.modilaynen@volvocars.com>, <mkl@pengutronix.de>
Cc: <drew@beagleboard.org>, <linux-can@vger.kernel.org>,
	<menschel.p@posteo.de>, <netdev@vger.kernel.org>,
	<will@macchina.cc>
Subject: RE: [net-next 6/6] can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register
Date: Tue, 21 Dec 2021 22:24:52 +0000	[thread overview]
Message-ID: <DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PR3P174MB01124C085C0E0A0220F2B11584709@PR3P174MB0112.EURP174.PROD.OUTLOOK.COM>

Hi Pavel,

> > > We have the similar CRC read errors but
> > > the lowest byte is not 0x00 and 0x80, it's actually 0x0x or 0x8x, e.g.
> > >
> > > mcp251xfd spi0.0 can0: CRC read error at address 0x0010 (length=4,
> > > data=82 d1 fa 6c, CRC=0xd9c2) retrying.
> > >
> > > 0xb0 0x10 0x04 0x82 0xd1 0xfa 0x6c => 0x59FD (not matching)
> > >
> > > but if I flip the first received bit  (highest bit in the lowest byte):
> > > 0xb0 0x10 0x04 0x02 0xd1 0xfa 0x6c => 0xD9C2 (matching!)
> 
> > What settings do you have on your setup? Can you please print the
> dmesg output from the init? I'm especially interested in Sysclk and SPI
> speed.
> 
> mcp251xfd spi0.0 can0: MCP2517FD rev0.0 (-RX_INT +MAB_NO_WARN
> +CRC_REG +CRC_RX +CRC_TX +ECC -HD c:40.00MHz m:10.00MHz
> r:10.00MHz e:10.00MHz) successfully initialized.

Thanks for the data. I've looked into this and it seems that the second bit being set in your case does not depend on the SPI-Rate (or the quirks for that matter) but it seems to be hardware setup related. 
I'm fine with changing the driver so that it ignores set LSBs but would limit it to 2 or 3 bits:
(buf_rx->data[0] == 0x0 || buf_rx->data[0] == 0x80))
becomes
((buf_rx->data[0] & 0xf8) == 0x0 || (buf_rx->data[0] & 0xf8) == 0x80)) {

The action also needs to be changed and the flip back of the bit needs to be removed. In this case the flipped databit that produces a matching CRC is actually  correct (i.e. consistent with the 7 LSBs in that byte.)
A patch could look like this (I'm currently not close to a setup where I can compile/test this.)

diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c
index 297491516a26..e5bc897f37e8 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c
@@ -332,12 +332,10 @@ mcp251xfd_regmap_crc_read(void *context,
                 *
                 * If the highest bit in the lowest byte is flipped
                 * the transferred CRC matches the calculated one. We
-                * assume for now the CRC calculation in the chip
-                * works on wrong data and the transferred data is
-                * correct.
+                * assume for now the CRC operates on the correct data.
                 */
                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;

@@ -347,10 +345,8 @@ mcp251xfd_regmap_crc_read(void *context,
                                                                  val_len);
                        if (!err) {
                                /* If CRC is now correct, assume
-                                * transferred data was OK, flip bit
-                                * back to original value.
+                                * flipped data was OK.
                                 */
-                               buf_rx->data[0] ^= 0x80;
                                goto out;
                        }
                }

Thanks,
Thomas

  reply	other threads:[~2021-12-21 22:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07  8:01 pull-request: can-next 2021-04-07 Marc Kleine-Budde
2021-04-07  8:01 ` [net-next 1/6] can: skb: alloc_can{,fd}_skb(): set "cf" to NULL if skb allocation fails Marc Kleine-Budde
2021-04-07  8:01 ` [net-next 2/6] can: m_can: m_can_receive_skb(): add missing error handling to can_rx_offload_queue_sorted() call Marc Kleine-Budde
2021-04-07  8:01 ` [net-next 3/6] can: c_can: remove unused enum BOSCH_C_CAN_PLATFORM Marc Kleine-Budde
2021-04-07  8:01 ` [net-next 4/6] can: mcp251xfd: add BQL support Marc Kleine-Budde
2021-04-07  8:01 ` [net-next 5/6] can: mcp251xfd: mcp251xfd_regmap_crc_read_one(): Factor out crc check into separate function Marc Kleine-Budde
2021-04-07  8:01 ` [net-next 6/6] can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register Marc Kleine-Budde
2021-04-21 19:58   ` Drew Fustini
2021-04-22  7:18     ` Marc Kleine-Budde
2021-04-22 16:46       ` Patrick Menschel
2021-05-07  7:25       ` Marc Kleine-Budde
2021-05-07  8:21         ` Patrick Menschel
2021-05-07  8:25           ` Marc Kleine-Budde
2021-05-08 18:36             ` Patrick Menschel
2021-05-09  7:46               ` Patrick Menschel
2021-05-10  7:45                 ` Marc Kleine-Budde
2021-05-20 10:29                   ` Patrick Menschel
2021-05-10  7:43               ` Marc Kleine-Budde
2021-12-07 16:53                 ` Modilaynen, Pavel
2021-12-08  8:54                   ` Marc Kleine-Budde
2021-12-09 10:22                   ` Thomas.Kopp
2021-12-09 11:17                     ` AW: " Sven Schuchmann
2021-12-09 11:27                       ` Marc Kleine-Budde
2021-12-09 12:53                         ` AW: " Sven Schuchmann
2021-12-13 22:12                     ` Modilaynen, Pavel
2021-12-21 22:24                       ` Thomas.Kopp [this message]
2022-06-21 14:25                         ` Marc Kleine-Budde
2022-06-22  8:19                           ` Marc Kleine-Budde
2022-06-22 13:47                           ` Thomas.Kopp
2022-06-26 19:14                         ` Marc Kleine-Budde
2021-05-07 22:36         ` Drew Fustini
2021-05-08 12:30           ` Marc Kleine-Budde
2021-04-07 22:10 ` pull-request: can-next 2021-04-07 patchwork-bot+netdevbpf

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=DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com \
    --to=thomas.kopp@microchip.com \
    --cc=drew@beagleboard.org \
    --cc=linux-can@vger.kernel.org \
    --cc=menschel.p@posteo.de \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=pavel.modilaynen@volvocars.com \
    --cc=will@macchina.cc \
    /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.