为v4.9内核反向移植mcp251xfd CAN驱动后配置can0报错：RTNETLINK answers: Argument list too long

我之前帮朋友排查过类似的旧内核反向移植CAN驱动的问题，这个错误大概率是新驱动与4.9内核CAN子系统的API/消息结构不兼容导致的——毕竟mcp251xfd原本是为5.x及以上内核设计的，和4.9的CAN子系统在参数传递、特性支持上有不少差异。下面是一步步的排查和解决思路：

1. 先尝试关闭CAN FD模式（最可能的快速修复） #

mcp251xfd默认可能启用了CAN FD特性，但4.9内核的CAN子系统原生不支持FD模式，当驱动尝试向内核上报FD相关参数时，就会触发参数列表过长的错误。你可以先强制关闭FD模式再启动设备：

sudo ip link set can0 type can bitrate 125000 fd off
sudo ip link set up can0

如果这能成功，那问题就出在FD模式的兼容性上，接下来只需要修改驱动代码，默认关闭FD模式即可：
在驱动的mcp251xfd_probe函数中，找到初始化priv->can.ctrlmode的地方，去掉CAN_CTRLMODE_FD位的设置，比如把：

priv->can.ctrlmode |= CAN_CTRLMODE_FD;

改成：

// 默认不启用FD模式，适配4.9内核
priv->can.ctrlmode &= ~CAN_CTRLMODE_FD;

2. 检查内核netlink消息大小限制 #

4.9内核的netlink默认缓冲区大小比新内核小，如果驱动在启动时上报的设备状态/参数消息过大，就会触发这个错误。你可以临时调整内核参数试试：

sudo sysctl -w net.core.rmem_max=262144
sudo sysctl -w net.core.wmem_max=262144

调整后再执行ip link set up can0，如果成功，说明是缓冲区大小的问题。可以把这两个参数添加到/etc/sysctl.conf里，让系统启动时自动生效：

net.core.rmem_max=262144
net.core.wmem_max=262144

3. 查看内核日志定位具体错误 #

执行dmesg -w打开实时内核日志，然后再执行ip link set up can0，观察内核输出的详细报错信息——比如有没有函数调用失败的堆栈、驱动打印的调试信息，这能帮你精准定位问题点：

• 如果日志里提到can_set_netlink_config相关的错误，那就是驱动传递的配置结构体和4.9内核的预期不匹配；
• 如果是寄存器初始化失败，那可能是驱动中某些硬件配置逻辑在4.9内核下有冲突。

4. 对比新老内核CAN子系统的API差异 #

重点对比4.9内核和mcp251xfd原生适配的内核（比如5.4）中net/can/目录下的代码：

• 查看struct can_netlink_config的字段差异：新内核可能扩展了这个结构体，而你移植的驱动用了新结构体的长度来传递参数，导致4.9内核认为参数过长；
• 检查can_setup、can_open等函数的调用逻辑：新驱动可能使用了4.9内核没有的API，或者传递了额外的参数。

找到差异后，修改驱动代码适配4.9内核的API即可——比如如果是结构体长度问题，就按照4.9内核的结构体定义来调整驱动中的参数传递逻辑。

内容的提问来源于stack exchange，提问作者acho