同一块板卡更换屏幕、触控器或外设后，常见的现象可能是“设备没出现”“驱动没有 probe”“probe 了但工作异常”。把这些问题混为一谈，会浪费大量调试时间。
先把故障归到正确层级
- 硬件与电源：供电、复位、时钟、引脚复用、I²C/SPI 总线电平与连接是否正确。
- 设备描述：设备树节点是否启用、compatible 是否匹配、地址/中断/GPIO 是否正确。
- 驱动构建：内核配置或模块是否启用，驱动是否已编入目标内核或成功加载。
- 驱动绑定：device 和 driver 是否匹配，probe 是否执行并成功完成。
- 上层使用：字符设备、子系统节点和用户态服务是否已发现且正确使用设备。
先收集可复现的版本与日志
uname -a
cat /proc/cmdline
dmesg -T | tail -n 150
lsmod | head
find /sys/bus -maxdepth 3 -type l 2>/dev/null | head这些命令偏向信息收集；具体设备节点、内核调试接口和权限因发行版及驱动而异。注意 dmesg 可能包含序列号、MAC 地址、设备路径等敏感数据，对外分享之前应脱敏。调试设备时最好同步记录固件版本、DTB 来源、原理图版本以及问题出现的条件。
有设备节点，不代表已经绑定成功
Linux 设备模型中，设备与驱动需要先完成匹配，再进入 probe。驱动的 probe 可能因资源未准备而返回 -EPROBE_DEFER；也可能因电源、时钟、总线通信、寄存器识别失败而报错。排查时需要区分“压根没有匹配”“发生延迟 probe”“probe 返回明确错误”三类情况。
| 现象 | 优先检查 |
|---|---|
| 设备不存在 | 总线枚举、设备树节点、硬件连接、地址、status。 |
| 驱动没有绑定 | compatible/ID 匹配、驱动是否构建、模块加载日志。 |
| 反复延迟 probe | 依赖的 regulator、clock、GPIO、reset 等资源是否可用。 |
| 绑定成功但功能异常 | 供电时序、固件/寄存器配置、中断、DMA、上层接口。 |
需要更多日志时怎么做
如果内核启用了 CONFIG_DYNAMIC_DEBUG，可以针对特定模块或源文件打开 pr_debug/dev_dbg 日志。切勿直接全局开启大量调试输出到生产设备；先在测试环境限定范围，并确认相关接口是否存在。
# 测试设备上的示例：模块名只是占位，先确认 dynamic debug 可用
cat /proc/dynamic_debug/control | head
# 按当前内核支持方式，谨慎启用某模块的调试输出
# echo 'module example_driver +p' > /proc/dynamic_debug/control修复后至少做一次回归验证
- 冷启动和热重启：检查 probe 顺序与电源初始化。
- 设备挂起/恢复：检查时钟、电源和中断状态。
- 异常注入：断开外设、复位失败或通信超时，确认驱动能正确处理。
- 版本固化：记录配置、补丁、编译器、镜像版本及回退路径。