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 機制的核心資料結構與函式是：
-
deferred_probe_pending_list，用來記錄哪些驅動被 deferred probe，並提供函式介面 driver_deferred_probe_add。
-
deferred_probe_work，用來排程相應的 work func 來執行 deferred probe 動作，並提供函式介面 driver_deferred_probe_trigger。
有了 driver-deferred-probe 機制後，編寫驅動程式時，除了某些驅動有嚴格的執行次序，需要特意去定義 initcall 等級之外，一般的驅動則無需太過關心驅動間的依賴，從而在一定程度上簡化了驅動開發。
以上就是對 EPRBOE_DEFER 的簡要介紹。
作者：bigfish99
部落格：https://www.cnblogs.com/bigfish0506/
公眾號：大魚嵌入式
