Hello Marc,
(in context of 5.15.1 Kernel)
1. I confirm the crashes with the command "cansend canX abc#" on each
can-if, which resulting in
[ 9563.137691] tcan4x5x spi0.0 can0: FIFO write returned -22
[ 9573.577950] tcan4x5x spi4.0 can1: FIFO write returned -22
[ 9658.948552] tcan4x5x spi6.0 can2: FIFO write returned -22
2. After applying of your Path the system is spammed until death with
messages (I have cut out the repeating):
[ 755.039082] tcan4x5x spi4.0 can1: ack error
[ 755.040039] tcan4x5x spi4.0 can1: ack error
[ 755.040071] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 755.040358] tcan4x5x spi4.0 can1: ack error
[ 755.040677] tcan4x5x spi4.0 can1: ack error
[ 755.040709] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 755.040997] tcan4x5x spi4.0 can1: ack error
[ 755.041029] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 755.041315] tcan4x5x spi4.0 can1: ack error
[ 755.041347] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 755.041635] tcan4x5x spi4.0 can1: ack error
[ 755.041667] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 755.041954] tcan4x5x spi4.0 can1: ack error
[ 755.041986] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 755.042017] tcan4x5x spi4.0 can1: __skb_queue_add_sort:
pos=0x00000000, new=0x00000000, diff= 0, queue_len=1
[ 755.042288] tcan4x5x spi4.0 can1: ack error
[ 755.042320] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
......
......
[ 807.210153] tcan4x5x spi4.0 can1: ack error
[ 807.210185] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 807.210216] tcan4x5x spi4.0 can1: __skb_queue_add_sort:
...
....
[ 807.212848] tcan4x5x spi4.0 can1: Protocol error in Arbitration fail
[ 807.212878] tcan4x5x spi4.0 can1: __skb_queue_add_sort:
pos=0x00000000, new=0x00000000, diff= 0, queue_len=1
Am 12.11.2021 um 14:07 schrieb Marc Kleine-Budde:
On 12.11.2021 13:11:06, Michael Anochin wrote:
Hello,
I use tcan4x5x over m_can driver with CANFD tcan4450 chip. Sometimes after
continuous communication I get in dmesg
tcan4x5x spi4.0 can1: FIFO read returned -22 . After that nothing works.
I have followed this behavior up to can_fd_dlc2len and found the following:
1. in m_can.c, function m_can_read_fifo does
cf->len = can_fd_dlc2len((fifo_header.dlc >> 16) & 0x0F);
cf->len = 0
DIV_ROUND_UP(cf->len, 4)
2. m_can_fifo_read(cdev, fgi, M_CAN_FIFO_DATA, cf->data,
DIV_ROUND_UP(cf->len, 4)) returns error because val_count=0
3. Following further chain with val_count=0:
cdev->ops->read_fifo(cdev, addr_offset, val, val_count) ->
tcan4x5x_read_fifo -> regmap_bulk_read -> ret -EINVAL
I can try to look deeper at fifo_header. Perhaps someone has the possible
cause of this behavior.
It seems the driver break when trying to send CAN frame with 0 length.
First try to reproduce if 'cansend can0 abc#' breaks the driver. Then
check if this patch helps:
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index ab4371aa4ff1..4278009c3eea 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -336,6 +336,9 @@ m_can_fifo_read(struct m_can_classdev *cdev,
u32 addr_offset = cdev->mcfg[MRAM_RXF0].off + fgi * RXF0_ELEMENT_SIZE +
offset;
+ if (val_count == 0)
+ return 0;
+
return cdev->ops->read_fifo(cdev, addr_offset, val, val_count);
}
@@ -346,6 +349,9 @@ m_can_fifo_write(struct m_can_classdev *cdev,
u32 addr_offset = cdev->mcfg[MRAM_TXB].off + fpi * TXB_ELEMENT_SIZE +
offset;
+ if (val_count == 0)
+ return 0;
+
return cdev->ops->write_fifo(cdev, addr_offset, val, val_count);
}
regards,
Marc
