I'm working with an RPi 4 running Buster and having a custom HAT. The HAT has two on-board MCP2518FD chips on SPI 0.0 and 0.1. Up till recently I've been using a custom build of kernel v4.19.73 with a slightly tweaked version of the msperl's mcp25xxfd driver: https://github.com/msperl/linux-rpi/releases and things have been going great. Now I want to take advantage of booting from a USB, however this has required merging in the more recent kernel v5.10.Y changes (v5.10.44). In doing so I've learned that a spin-off of the mcp25xxfd has found its way into the mainstream and renamed to mcp251xfd. I have installed the new custom kernel and tried both the mcp25xxfd I had been using AND the new mcp251xfd driver, but neither are working reliably. On the rare chance (1 out of many restarts) one is working properly I can do a candump and see traffic as expected, however almost always when I go to bring up the CAN port I receive: "RTNETLINK answers: Connection timed out" and looking at dmesg I see combinations of "SPI transfer timed out", "failed to transfer one message from queue", and "CRC read error at address 0x...". Since the hardware works with the old software I have no reason to think it's a hardware issue and if it were a driver issue I'd think someone else has seen this by now and that patch would have been issued (I started with v5.10.17 a few months ago and updated to v5.10.44 today now that I'm back to working on this issue). Looking at "dmesg" and "vcdbg log msg" I don't see any major differences between when things work and when they do not, when they do work it's for one reboot and then the following are all messed up till the random one off when they aren't. I accidentally shutdown the system and I don't have physical access to it again till Monday, so bare with me on logs and whatnot, I'll get whatever you all want to see then. Has anyone else seen this behavior and/or have experience with using the MCP2518FD chip on an RPi 4 running Buster and having a 5.10.Y variant of the kernel??

I've attached three files... my /boot/config.txt and dmesg logs where things worked and things were broken when I ran the ip link commands.

Attached Files

	config.txt (2.7 KB, 50 views)
	dmesg_loaded_mcp251xfd.txt (22.4 KB, 50 views)
	dmesg_loaded_mcp251xfd_broken.txt (24.1 KB, 32 views)

So, how exactly did you migrate from your old kernel to the newer one?

I'm currently migrating from 5.8 to 5.12 on quite ordinary hardware, and it's quite alot of work. Depreciated functions, matured ones and more or less relevant dependencies, changed drivers and many more things. A move from 4.19 to 5.10 could create a number of issues.

For us we just ran the applicable apt upgrade commands and were left with kernel 5.10.Y, then from there I built a new custom kernel by branching off of 5.10.Y RPi Linux branch and applying whatever changes were needed (not very many and I ditched the MCP25XXFD driver for the MCP251XFD in the mainstream now). Initially I copied over our existing kernel config files, but later I remade them using the default config files present and made the necessary changes for our system, again not too many.

Finally narrowing down this problem today, it would appear that the problem only crops up when I've got the I2S bits enabled; disable I2S and the CAN stuff on SPI0 works great. Any ideas?