扫码关注
驱动没有probe成功时，最忌讳直接改代码猜。Linux驱动是否进入probe、为什么返回错误、设备树是否匹配、时钟/复位/GPIO/regulator是否就绪，都可以从日志和内核状态中找到证据。
先确认驱动模块是否加载、compatible是否匹配以及probe是否真正被调用。
dmesg中的返回码和deferred probe信息通常是最直接的线索。
设备树中的reg、interrupts、clocks、resets、gpios和regulator等依赖要逐项核对。
-EPROBE_DEFER并不一定是错误，可能只是依赖资源暂时未准备好。
面试官主要考察什么
这类题更看重工程判断过程。建议先说明前提条件，再解释原理，然后给出设计或排查动作，最后说明如何验证。遇到具体数值时，要明确以器件数据手册、接口规范、板厂能力或实际测量为依据。
关键分析点
第一步
检查：dmesg和驱动是否注册成功
常见误区：没有日志证据就直接改设备树
匹配关系
检查：compatible、设备树节点状态和驱动match table
常见误区：节点存在就认为一定会probe
资源依赖
检查：clock、reset、GPIO、IRQ、regulator等获取结果
常见误区：只盯着reg地址
返回码
检查：probe具体在哪一步失败以及errno
常见误区：把-EPROBE_DEFER当成永久失败
参考回答
我会先用dmesg确认驱动是否注册以及probe有没有进入。如果完全没进入，优先看compatible和设备树节点状态；如果进入后失败，就沿着日志和返回码定位到具体资源获取步骤。很多平台驱动依赖clock、reset、GPIO、IRQ或regulator，其中任意一个provider还没准备好都可能导致deferred probe。排查时我会按“匹配→probe→资源→返回码”顺序走，而不是一上来就改内核源码。
面试官可能继续追问
-EPROBE_DEFER是什么意思？
compatible匹配了为什么probe仍然不进？
设备树节点status="disabled"会怎样？
如何快速判断是驱动问题还是资源provider问题？
这些回答容易失分
看到probe失败就重编内核。
不看errno，只说“驱动没起来”。
忽略clock、reset和regulator等依赖资源。
面试前怎么准备
熟悉dmesg、lsmod、modprobe等基础工具。
看懂一个platform_driver的of_match_table和probe。
准备一次设备树资源配置错误导致probe失败的案例。
核心关键词：Linux驱动、probe失败、dmesg、设备树、EPROBE_DEFER、嵌入式Linux面试
