01

60 秒回答模板

probe 没执行要先拆成两类问题：模块还没被自动加载，和模块已经加载但设备驱动没有匹配。自动加载失败时查 MODULE_DEVICE_TABLE、modules.alias、udev/modprobe 和模块别名；手动 insmod 后仍不进 probe，则 MODULE_DEVICE_TABLE 不是主因，要优先查 platform_device 是否真的生成、设备树 status、板子实际 dtb、compatible 和 of_match_table 是否一致、platform_driver_register 是否执行，以及是否被 deferred probe 卡住。排查顺序是先看 dmesg 和 lsmod，再看 /sys/bus/platform/devices 与 drivers，反编译当前 dtb 确认节点，最后确认 match 表和 probe 返回值。

考点 三段排查
难度 真实面经题
回答目标 证明自己能按 Linux 设备模型定位 platform 驱动不绑定的根因。
02

深入解析

01

先分清自动加载还是匹配失败

如果驱动模块根本没有自动加载，要查 MODULE_DEVICE_TABLE、modules.alias、udev/modprobe 和模块安装路径；如果已经手动 insmod 或内建进内核但 probe 不执行，重点就变成设备是否生成、驱动是否注册和 match 是否成功。

02

设备不存在就不会 probe

platform 绑定需要 platform_device 和 platform_driver 两边都存在。设备树节点 status 不是 okay、父节点关闭、compatible 节点路径不对，或板子实际启动的 dtb 不是你改的那个，都会导致设备没有生成。

03

匹配失败看 compatible 和表项

设备树匹配依赖 compatible 与 of_match_table 完全对应，大小写、厂商前缀、逗号、下划线都可能导致失败。非设备树路径还要看 driver name 与 platform_device name。

04

不要把 deferred probe 当没调用

如果缺 regulator、clock、gpio、pinctrl 等依赖资源，probe 可能已经调用但返回 -EPROBE_DEFER。此时 dmesg、deferred_probe 列表和 probe 内日志能区分“没进入 probe”和“进入后延迟”。

03

易错点

  • 一上来就改 probe 代码，没确认设备和驱动是否已经匹配。
  • 只检查源码 dts，不确认板子实际启动的 dtb。
  • 把 probe 返回错误或延迟探测误判为 probe 没执行。
  • 漏掉 MODULE_DEVICE_TABLE，导致模块自动加载问题解释不完整。
04

面试官追问

compatible 匹配成功后 probe 一定马上执行吗？

不一定。如果依赖资源还没准备好，probe 可能返回延迟探测；如果总线或父设备还没完成，也可能稍后再尝试。

手动 insmod 后 probe 没来，第一步看什么？

先看 /sys/bus/platform/devices 有没有对应设备，再看驱动目录和 dmesg。如果设备都没有，优先查设备树和 dtb。

如果面试官让你现场排查，你会先看哪些证据？

我会先看 dmesg 和返回码，再查 /sys 下设备、驱动和资源状态，必要时加 trace/ftrace 或最小日志，先证明问题出在设备生成、匹配、资源获取、回调路径还是用户态交互。