Re: can, tcan4x5x: look to merge rpi support into rpi kernel tree - Marc Kleine-Budde

From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Torin Cooper-Bennun <torin@maxiluxsystems.com>
Cc: linux-can <linux-can@vger.kernel.org>
Subject: Re: can, tcan4x5x: look to merge rpi support into rpi kernel tree
Date: Tue, 16 Feb 2021 13:32:35 +0100	[thread overview]
Message-ID: <20210216123235.i63toczore5vfftp@hardanger.blackshift.org> (raw)
In-Reply-To: <CAALJrqjGKPo+5B_qBX1b0hAheiaZk4so85OrjQT=1d51Vj8a=w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]

On 16.02.2021 11:38:17, Torin Cooper-Bennun wrote:
> > Where do you see these blank frames? On the sending rpi with candump? An
> > on the bus (with a second system) you only see the full 8 byte long
> > frames?
> 
> My apologies, I should have clarified. The Pi is receiving all these
> frames. The sending node is sending the same frame every time (I'll
> have it send increasing IDs from now on).

This means the tcan receives two "ghost" frames here?

| can0  001   [8]  00 01 02 03 04 05 06 07
| can0  001   [8]  00 01 02 03 04 05 06 07
| can0  001   [8]  00 01 02 03 04 05 06 07
| can0  000   [0]
| can0  000   [0]
| can0  001   [8]  00 01 02 03 04 05 06 07
| can0  001   [8]  00 01 02 03 04 05 06 07

If the tcan driver shuts down the tcan chip properly, depending on your
setup, the sending CAN node might be the only one on the bus, leading to
repeat the CAN frame due to no ACK. This easily triggers race conditions
when starting up the tcan driver again.

With proper timestamps and increasing CAN-IDs you can figure out if the
driver clears the bits on the CAN messages (number of blank frames ==
number of missing frames) or if it "inserts" blank frames (== no missing
frames).

If the number of blank frames equals the number of missing frames, then
have a look where the message RAM is initialized:

    https://elixir.bootlin.com/linux/latest/source/drivers/net/can/m_can/tcan4x5x.c#L335

Oh! This doesn't look right :(

I think it's a bad idea to first bring the chip into normal mode and
then initialize the RAM.

> > Use "candump any,0~0,#FFFFFFFF -extA" to get RX/TX annotation.
> > Use "cangen -Ii -L8 -D000102030405060708 -g100 can0" to get increasing
> > CAN-IDs, so you can figure out if a CAN frame got lost.
> 
> Fab, thank you.
> 
> > Seems I have to add the TX path to the list of broken things...
> >
> > The mcp251xfd driver can be used as a template for the tcan4x5x driver.
> 
> I'll go ahead and compare with mcp251xfd and continue testing. I'll be
> working towards getting this stable in the coming weeks.

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]