扫码关注
题库分类：嵌入式Linux适合经验：1—5年难度：中高级题型：驱动调试题 + 项目追问题
面试题
设备树已经添加节点，驱动模块也能加载，但设备没有正常工作。你怎样判断是驱动没有匹配、probe没有执行，还是probe执行后失败？
面试官真正想考什么
这道题考的是Linux设备模型和调试顺序。很多回答一上来就改寄存器或怀疑硬件，却没有先确认设备有没有被枚举、驱动有没有注册、总线匹配是否成功。把不同阶段混在一起，会让排查反复绕圈。
回答思路
第一步：保留完整日志并确认设备是否出现
先保存从内核启动到加载驱动的完整日志，确认设备树二进制是否是本次构建和实际启动使用的版本。通过对应总线的sysfs目录查看设备是否被创建；如果设备根本不存在，优先检查设备树节点位置、status状态、父总线是否正常以及固件是否传入正确DTB。
第二步：检查驱动注册和匹配条件
确认模块是否加载、驱动是否出现在对应的sysfs驱动目录，并核对设备树compatible与驱动of_match_table。对于I²C、SPI或平台设备，还要确认父控制器已经probe成功。名称相似不等于匹配成功，字符串、总线类型和模块别名都要以运行系统为准。
第三步：给probe建立明确入口证据
在probe入口和关键阶段保留有意义的日志，返回错误时传播准确的负错误码。若进入probe后失败，就按时钟、复位、reg映射、中断、GPIO、regulator、DMA等资源获取顺序定位。不要把所有失败统一返回一个错误，否则日志无法区分资源不存在、参数错误和暂时未就绪。
第四步：正确理解延迟探测
如果消费者依赖的时钟、电源或其他供应者驱动尚未就绪，probe可能返回延迟探测错误，内核稍后会再次尝试。此时应查看延迟原因和供应者状态，而不是简单循环重试。若真正缺少设备树属性或驱动，延迟探测也不会自动修复配置错误。
第五步：软件路径确认后再查硬件
只有确认设备匹配、资源获取和初始化代码已执行，才进一步用示波器、逻辑分析仪检查电源、复位、时钟和总线事务。这样能回答“代码有没有走到写寄存器之前”和“硬件是否对写操作有响应”两个不同问题。
可直接使用的参考回答
我会把问题分成设备创建、驱动匹配和probe执行三个阶段。先看启动日志与sysfs，确认实际DTB中节点有效、父总线已注册并创建了设备；再检查驱动是否注册到同一总线，以及compatible、ID表和模块别名是否匹配。
如果probe已经进入，就按资源获取和硬件初始化步骤查看准确错误码，特别检查时钟、电源、复位、中断和GPIO。遇到延迟探测时查供应者是否就绪，而不是盲目重试。软件路径确认后，再用仪器验证电源、复位、时钟与总线波形，形成从内核日志到硬件信号的完整证据链。
面试官可能继续追问
模块加载成功是否代表设备已经绑定？
不代表。模块加载只说明代码进入内核，仍需设备存在并与驱动匹配后才会调用probe。compatible写对了为什么还不进probe？
还可能是节点未启用、父总线未工作、DTB未更新、驱动未注册到正确总线或模块未包含匹配表。延迟探测应该怎样查看？
结合内核日志、设备延迟原因和供应者驱动状态判断具体依赖。probe失败后怎样避免资源泄漏？
优先使用设备管理资源接口，并确保每个失败分支正确释放已申请资源。
容易失分的表达
“模块能insmod，驱动肯定加载成功。”——混淆代码加载与设备绑定。
“probe不进就是硬件坏了。”——匹配和枚举发生在硬件访问之前。
“所有错误都返回-1。”——丢失了定位所需的错误语义。
面试前准备动作
在开发板上找一个已绑定设备，沿sysfs查看device与driver链接。
准备一次compatible拼写错误与供应者未就绪的对比案例。
整理probe中资源申请、错误返回和硬件初始化的顺序图。
参考资料
Linux Kernel Documentation：Platform Devices and Drivers
Linux Kernel Documentation：Linux and the Devicetree
Linux Kernel Documentation：Driver Infrastructure and Deferred Probe
核心关键词：Linux驱动probe失败、设备树compatible、驱动绑定、延迟探测、嵌入式Linux面试、sysfs
