Re: can, tcan4x5x: look to merge rpi support into rpi kernel tree

[Torin Cooper-Bennun <torin@maxiluxsystems.com>]

On Mon, 15 Feb 2021 at 17:44, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Do you have the wake-gpio in your DT? This one works for me:

We actually don't break out WAKE on our board, and using this board
I've written a TCAN4550 driver for MCUs and haven't required device
wake-up via WAKE or other means.

My DT:

|            tcan4x5x: tcan4x5x@0 {
|                reg = <0>;
|                compatible = "ti,tcan4x5x";
|                pinctrl-names = "default";
|                pinctrl-0 = <&tcan4x5x_pins>;
|                spi-max-frequency = <4000000>;
|                bosch,mram-cfg = <0x0 0 0 10 0 0 0 10>;
|                interrupt-parent = <&gpio>;
|                interrupts = <25 IRQ_TYPE_LEVEL_LOW>;
|                clock-names = "cclk";
|                clocks = <&clk_tcan4x5x_osc>;
|            };

> You mean something like these...
>
> | [  543.116807] WARNING: CPU: 0 PID: 11 at lib/refcount.c:25 refcount_warn_saturate+0x108/0x174
> | [  543.116820] refcount_t: addition on 0; use-after-free.
>
> with can_put_echo_skb() in the call stack?
>
> | [  543.117745] [<bf186edc>] (can_put_echo_skb [can_dev]) from [<bf1d67ec>] (mcp251xfd_start_xmit+0x2b0/0x3bc [mcp251xfd])

Yes, exactly. I have also seen, when putting the interface down...

[   69.378407] WARNING: CPU: 3 PID: 740 at lib/refcount.c:28
refcount_warn_saturate+0x13c/0x174
[   69.378413] refcount_t: underflow; use-after-free.

...with can_flush_echo_skb() in the stack this time:

[   69.378857] [<7f1de528>] (can_flush_echo_skb [can_dev]) from
[<7f1de5c8>] (close_candev+0x2c/0x30 [can_dev])

> > This is a Raspberry Pi 3 Model B v1.2, hosting a TCAN4550 on spi0. The
> > external oscillator for the TCAN4550 is 20 MHz.
>
> Is that a custom tcan pi hat, or is it officially sold somewhere?

It's a custom board, jerry-rigged to a Pi.

> First thing I'd do is to rewrite the RX function and IRQ handler for the
> "peripheral", that's the code path used for the SPI attached m-can
> core. TX doesn't look efficient, but it should work at least.

Thanks, I'll take a look. I am concerned about this weird behaviour
when trying to TX, though. I'll walk through the chip config and
compare with my known working process.

-- 
Regards,

Torin Cooper-Bennun
www.maxiluxsystems.com | Software Engineer