​Linux kernel 驱动中，有不少驱动会引用到 EPROBE_DEFER 这个错误号。比如下面这个例子，对 devm_gpiod_get 的返回值进行判断，如果有错误且错误号不是 -EPRBOE_DEFER ，才输出error log。

那么 EPRBOE_DEFER 有什么特别之处吗，需要驱动程序这样特意处理？这个与 kernel 设计的 driver-deferred-probe 机制有关。

kernel 下有多个独立的驱动，每个驱动或多或少地会引用到其他驱动提供的资源，比如某个外设驱动需要使用 gpio 资源，就会通过 gpio 驱动提供的函数接口去申请 gpio；但是当A驱动引用B驱动提供的资源时，B驱动可能还没有工作起来， 为了解决驱动之间的这种依赖关系，kernel 设计了 driver-deferred-probe 机制：某个驱动在 probe 过程中，如果遇到依赖的资源还没有准备好，那么就返回 -EPRBOE_DEFER，kernel 检测到该驱动返回的是  -EPRBOE_DEFER，就会在过一段时间后让该驱动再次 probe。

driver-deferred-probe 流程如下图所示，有三条可能的路径 ：

生成新的 device 时

注册新的 driver 时

later_initcall 主动再次触发

有了 driver-deferred-probe 机制后，编写驱动程序时，除了某些驱动有严格的执行次序，需要特意去定义 initcall 等级之外，一般的驱动则无需太过关心驱动间的依赖，从而在一定程度上简化了驱动开发。

以上就是对 EPRBOE_DEFER 的简要介绍。

作者：bigfish99

博客：https://www.cnblogs.com/bigfish0506/

公众号：大鱼嵌入式