linux如何编写can驱动
我准备在 Linux 中做 CAN 通信驱动开发，但不确定应该先确认哪些底层条件。除了控制器型号外，还需要关注哪些和总线、时钟、收发器相关的信息，才能避免驱动适配出问题？
开发前需要确认的关键条件
在编写 Linux CAN 驱动之前，建议先确认 CAN 控制器型号、寄存器布局、时钟源、复位方式、中断类型，以及外部收发器的连接方式。还要明确是 CAN 2.0 还是 CAN FD，硬件是否支持过滤器、时间戳、错误状态上报等能力。对于平台设备，还需要确认设备树或板级描述是否已经把地址、中断号、时钟和 GPIO 控制信息描述完整。
我希望写出来的驱动能直接接入 Linux 网络栈，并且让上层应用通过 SocketCAN 发送和接收报文。驱动里一般要提供哪些关键能力，才能算是一个可用的 CAN 驱动？
CAN 驱动的核心实现内容
一个可用于 SocketCAN 的 CAN 驱动，通常需要完成设备初始化、发送和接收路径、中断处理、错误状态处理、硬件过滤配置以及链路状态管理。驱动还要注册为网络设备，向内核上报 CAN 帧，并接收来自 SocketCAN 的发送请求。若硬件支持，还可以实现 CAN FD、时间戳、错误帧和总线关闭恢复等扩展能力。
我对 Linux 网络驱动比较熟悉，但 CAN 驱动的收发流程和普通网卡不太一样。内核里一般怎样把用户态发来的 CAN 帧送到硬件，又怎样把硬件收到的帧交给上层应用？
CAN 收发与网络框架的对接方式
在 Linux 中，CAN 驱动通常以网络设备方式接入内核。发送时，SocketCAN 会把用户态报文传给驱动的发送接口，驱动再把数据写入硬件发送邮箱或 FIFO。接收时，硬件触发中断或轮询，驱动从接收寄存器取出 CAN 帧，转换成内核可识别的 skb，再通过网络栈上报。若发生发送失败、总线错误或仲裁丢失，驱动也需要及时更新状态并通知上层。
我在移植 CAN 驱动后，可能会遇到收不到包、发不出去、总线一直报错等问题。调试这类问题时，通常应该优先检查哪些环节，才能更快定位问题来源？
CAN 驱动调试的重点排查方向
调试 CAN 驱动时，建议重点检查时钟是否正确、波特率配置是否匹配、收发器是否正常供电、终端电阻是否安装到位，以及中断是否能正确触发。还要确认控制器是否已从初始化态切换到工作态，接收过滤器是否拦截了报文，发送队列是否被堵塞。借助 dmesg、ip link、candump、cansend 等工具，可以较快判断问题出在硬件层、驱动层还是协议配置层。