#
e3d4ee7d |
|
21-Dec-2021 |
Thomas Kopp <thomas.kopp@microchip.com> |
can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround broken CRC on TBC register 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. New investigations and simulations indicate that the CRC send by the device is calculated on correct data, and the data is incorrectly received by the SPI host controller. Use flipped instead of original data and update workaround description in mcp251xfd_regmap_crc_read(). [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 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>
|
#
406cc9cd |
|
21-Dec-2021 |
Thomas Kopp <thomas.kopp@microchip.com> |
can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround handling for mcp2517fd 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>
|
#
c912f19e |
|
21-May-2021 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: introduce struct mcp251xfd_tx_ring::nr and ::fifo_nr and make use of it This patch removes the hard coded assumption that the TX ring uses hardware FIFO 1. This allows the hardware FIFO 1 to be used for RX and the next free FIFO for TX. This gives the opportunity to minimize the number of SPI transfers in the IRQ handler. The read of the IRQ status register and RX FIFO status registers can be combined into single SPI transfer. If the RX ring uses FIFO 1, the overall length of the transfer is smaller than in the original layout, where the RX FIFO comes after the TX FIFO. Link: https://lore.kernel.org/all/20220217103826.2299157-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
25386c9a |
|
29-Oct-2020 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: mcp251xfd_regmap_crc_read(): ignore CRC error only if solely OSC register is read MCP251XFD_REG_OSC is the first register the driver reads from. The chip may be in deep sleep and the SPI transfer (i.e. the assertion of the CS) will wake the chip up. This takes about 3ms. The CRC of this transfer is wrong, or there isn't any chip at all, in this case the CRC will be wrong, too. The driver ignores the CRC error and returns the read data to the caller. To avoid any confusion, this patch changes the mcp251xfd_regmap_crc_read() function to only ignore the CRC error if solely the OSC register is read. So when reading more than the OSC registers at once, CRC errors are not ignored. Link: https://lore.kernel.org/all/20220207131047.282110-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
2d211669 |
|
27-Nov-2021 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: remove double blank lines This patch removes double blank lines from the driver. Link: https://lore.kernel.org/all/20220105154300.1258636-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
c7eb923c |
|
15-Mar-2021 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register MCP251XFD_REG_TBC is the time base counter 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. To reproduce this problem let the driver read the TBC register in a high frequency. This can be done by attaching only the mcp251xfd CAN controller to a valid terminated CAN bus and send a single CAN frame. As there are no other CAN controller on the bus, the sent CAN frame is not ACKed and the mcp251xfd repeats it. If user space enables the bus error reporting, each of the NACK errors is reported with a time stamp (which is read from the TBC register) to user space. $ ip link set can0 down $ ip link set can0 up type can bitrate 500000 berr-reporting on $ cansend can0 4FF#ff.01.00.00.00.00.00.00 This leads to several error messages per second: | mcp251xfd spi0.0 can0: CRC read error at address 0x0010 (length=4, data=00 3a 86 da, CRC=0x7753) retrying. | mcp251xfd spi0.0 can0: CRC read error at address 0x0010 (length=4, data=80 01 b4 da, CRC=0x5830) retrying. | mcp251xfd spi0.0 can0: CRC read error at address 0x0010 (length=4, data=00 e9 23 db, CRC=0xa723) retrying. | mcp251xfd spi0.0 can0: CRC read error at address 0x0010 (length=4, data=00 8a 30 db, CRC=0x4a9c) retrying. | mcp251xfd spi0.0 can0: CRC read error at address 0x0010 (length=4, data=80 f3 43 db, CRC=0x66d2) retrying. 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. This patch implements the following workaround: - If a CRC read error on the TBC register is detected and the lowest byte is 0x00 or 0x80, the highest bit of the lowest 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. Link: https://lore.kernel.org/r/20210406110617.1865592-5-mkl@pengutronix.de Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
ef7a8c3e |
|
15-Mar-2021 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: mcp251xfd_regmap_crc_read_one(): Factor out crc check into separate function This patch factors out the crc check into a separate function. This is preparation for the next patch. Link: https://lore.kernel.org/r/20210406110617.1865592-4-mkl@pengutronix.de Cc: Manivannan Sadhasivam <mani@kernel.org> Cc: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
da623840 |
|
19-Oct-2020 |
kernel test robot <lkp@intel.com> |
can: mcp251xfd: mcp251xfd_regmap_nocrc_read(): fix semicolon.cocci warnings drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c:176:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 875347fe5756 ("can: mcp25xxfd: add regmap infrastructure") Signed-off-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20201019120805.GA63693@ae4257e0ab22 Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
b4728920 |
|
15-Oct-2020 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: mcp251xfd_regmap_crc_read(): increase severity of CRC read error messages During debugging it turned out that some people have setups where the SPI communication is more prone to CRC errors. Increase the severity of both the transfer retry and transfer failure message to give users feedback without the need to recompile the driver with debug enabled. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Thomas Kopp <thomas.kopp@microchip.com> Link: http://lore.kernel.org/r/20201019190524.1285319-15-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
eb79a267 |
|
30-Sep-2020 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: rename all remaining occurrence to mcp251xfd In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes all non user facing occurrence of "mcp25xxfd" to "mcp251xfd" and "MCP25XXFD" to "MCP251XFD". [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-10-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
#
1f0e21a0 |
|
30-Sep-2020 |
Marc Kleine-Budde <mkl@pengutronix.de> |
can: mcp251xfd: rename driver files and subdir to mcp251xfd In [1] Geert noted that the autodetect compatible for the mcp25xxfd driver, which is "microchip,mcp25xxfd" might be too generic and overlap with upcoming, but incompatible chips. In the previous patch the autodetect DT compatbile has been renamed to "microchip,mcp251xfd", this patch changes the name of the driver subdir and the individual files accordinly. [1] http://lore.kernel.org/r/CAMuHMdVkwGjr6dJuMyhQNqFoJqbh6Ec5V2b5LenCshwpM2SDsQ@mail.gmail.com Link: https://lore.kernel.org/r/20200930091424.792165-8-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|