driver_defe...robe_trigger(9)

💅 driver_deferred_probe_trigger — from the Kernel API Manual, bestie ✨

okay so real talk, this one is from the Kernel API Manual, and it's called driver_deferred_probe_trigger. yes the title got truncated with ... in the header, that's just how the page prints, don't come for me 🫶

---

🌸 NAME 🌸

driver_deferred_probe_trigger — the function that kicks off re-probing of all your deferred devices 💖 like literally the "go go go" button

---

✨ SYNOPSIS ✨

void driver_deferred_probe_trigger (void );

---

🎀 ARGUMENTS 🎀

• void — no arguments. that's it. nothing. zero. empty set. she takes no notes, she takes no input 💅

---

🦋 DESCRIPTION 🦋

okay so here's the tea ☕ — this function moves all devices from the pending list over to the active list, and then it schedules the deferred probe workqueue to actually go process them. it's giving "everybody up, we're doing this now" energy ✨

the rule of thumb: you should call it anytime a driver is successfully bound to a device. like, probe worked?? slay, ring the bell, tell the deferred squad 🔔

⚠️ but bestie, hear me out, because there's a race condition in multi-threaded probe and it's not cute 😭

here's the situation: when more than one device is probing at the same time, it's totally possible for one probe to complete successfully while another one is about to defer. and if that second one depends on the first one? yeah. it gets put on the pending list after the trigger event already happened, and it just... sits there. stuck. forever. perish 💀

so to deal with that, there's an atomic called deferred_trigger_count 👑 and its whole job is to figure out whether a successful trigger happened while a driver was mid-probe. so the logic is:

• if the trigger count changes in the midst of a probe → deferred processing should be triggered again 🔁

no cap, that's the whole safety net. keep an eye on the count or your device is gonna be waiting in the queue like an unread text 🙈

---

🌈 SEE ALSO 🌈

• Kernel file ./drivers/base/dd.c 👀 that's where the lore lives
• device_block_probing(9)
• device_unblock_probing(9)
• device_set_deferred_probe_reason(9)
• driver_deferred_probe_check_state(9)
• deferred_probe_initcall(9)
• device_is_bound(9)
• device_bind_driver(9)
• driver_probe_done(9)
• wait_for_device_probe(9)
• driver_probe_device(9)
• device_attach(9)
• device_driver_attach(9)
• driver_attach(9)
• device_release_driver(9)
• device_driver_detach(9)
• driver_detach(9)

---

okay that's the whole page, you ate that 🍓 and for the cute lil sign-off: this one lives over in ./drivers/base, it's dated October 2026, and the page itself is driver_defe...robe_trigger(9) — yes the truncation is part of the aesthetic, mwah 💜✨