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

Marc Kleine-Budde mkl at pengutronix.de
Mon Feb 15 12:44:08 EST 2021


I've added the linux-can mailing list on Cc.

On 15.02.2021 15:41:57, Torin Cooper-Bennun wrote:
> On Mon, 15 Feb 2021 at 14:45, Marc Kleine-Budde <mkl at pengutronix.de> wrote:
> > Sadly, the driver is still not in good shape...I think it will explode
> > as soon as you receive a CAN frame on the rpi, as the frames are passed
> > into the networking stack from the wrong context...
> >
> > Maybe I'll find some time to get receive properly working.
> 
> I'm afraid I've just found that myself -- in fact, I'm having problems
> getting TX to behave as well. I think the chip configuration is
> incorrect (at the very least, the chip is never put into standby mode,
> which the datasheet says is paramount!)

Do you have the wake-gpio in your DT? This one works for me:

|         tcan4x5x: tcan4x5x at 1 {
|                 reg = <1>;
|                 compatible = "ti,tcan4x5x";
|                 vsup-supply = <&reg_tcan4x5x_vsup>;
|                 pinctrl-names = "default";
|                 pinctrl-0 = <&pinctrl_tcan4x5x>;
|                 spi-max-frequency = <10000000>;
|                 bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>;
|                 interrupt-parent = <&gpio4>;
|                 interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
|                 clock-names = "cclk";
|                 clocks = <&tcan4x5x_osc>;
|                 device-wake-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH>;
|         };

> The current config procedure
> ends up with bizarre activity on the CAN lines. I also observed
> intermittent refcount warnings during driver use.

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])

We tried to fix the problem, but the patch made the problem more
visible. Working on this.

> I've cherry-picked the relevant changes onto RPi kernel 5.10 :
> https://github.com/tcbennun/linux/commit/c32a0d422b551390f6960243f29e1afacfe30d48
> and I'll be next trying the bleeding-edge driver with 5.11.
> 
> > BTW: what kind of hardware are you using?
> 
> 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?

> Since you've confirmed it needs work, I'll probably be able to put
> some time into it myself.

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.

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 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20210215/bc1d61c8/attachment.sig>


More information about the linux-rpi-kernel mailing list