In this patch series, rx-offload is utilised in the m_can driver, instead of sending skbs directly from a threaded IRQ using netif_receive_skb() (which is meant to be called only from a softirq context). This should fix the major stability problems with M_CAN peripherals (tcan4x5x being the only practical example at the moment). I have tested this with a Raspberry Pi 3 Model B and a TCAN4550. The driver no longer crashes outright, and TX works consistently and echoes correctly. RX is also much more stable, but I think more testing is required with different hardware to really ensure stability. There is definitely at least one outstanding issue. In my tests, if the TCAN4550 encounters bus activity immediately after init, such that RX FIFO 0 is already full by the time the IRQ handler is first called, then in the initial round of RX polling, the frames are apparently read out empty (DLC = 0, ID = 0). After this point, RX works as expected. I assume there's a data race hidden in the init process somewhere, but I have failed to find it! On my hardware setup, I still have occasional incorrectly-read-out frames (e.g. DLC wrong, or the odd 4 data bytes reading 0), but I am yet to rule out SPI signal problems, nor Raspberry Pi SPI hardware problems. In any case, these problems existed in my setup before this patch series. I would be grateful if someone were able to test these changes with a different hardware setup, and also with non-peripheral M_CAN. Many thanks, Torin
