Re: [net-next 6/6] can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21.06.2022 16:25:15, Marc Kleine-Budde wrote:
> > 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.)

The mcp2517fd errata says the transmitted data is okay, but the CRC is
calculated on wrong data:

| It is possible that there is a mismatch between the transmitted CRC
| and the actual CRC for the transmitted data when data are updated at a
| specific time during the SPI READ_CRC command. In these cases, the
| transmitted CRC is wrong. The data transmitted are correct.

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde           |
Embedded Linux                   | https://www.pengutronix.de  |
Vertretung West/Dortmund         | Phone: +49-231-2826-924     |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-5555 |

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux