ENUM PROBE_TYPE(9)

✨ enum probe_type(9) ✨

okay bestie, welcome to the enum probe_type(9) page from the Kernel API Manual 💖 this is the whole vibe:

💅 NAME 💅

enum probe_type — the device driver probe type to try. Device drivers may opt in for special handling of their respective probe routines. This tells the core what to expect and prefer. periodt ✨

🌸 SYNOPSIS 🌸

enum probe_type {
    PROBE_DEFAULT_STRATEGY ,
    PROBE_PREFER_ASYNCHRONOUS ,
    PROBE_FORCE_SYNCHRONOUS

};

🎀 Constants 🎀

• PROBE_DEFAULT_STRATEGY — used by drivers that work equally well whether probed synchronously or asynchronously. no cap, they’re flexible like that 🫶
• PROBE_PREFER_ASYNCHRONOUS — drivers for “slow” devices whose probing order is not essential for booting the system may opt into executing their probes asynchronously ✨ it’s giving “we can do this later, it’s fine” energy.
• PROBE_FORCE_SYNCHRONOUS — use this to annotate drivers that need their probe routines to run synchronously with driver and device registration. ⚠️ with the exception of -EPROBE_DEFER handling — re-probing always ends up being done asynchronously. that part is not optional, bestie 💀

🦋 Description 🦋

note that the end goal is to switch the kernel to use asynchronous probing by default, so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary measure that allows us to speed up boot process while we are validating the rest of the drivers. it’s a whole work-in-progress moment, and honestly? we love a transitional era 👑

🌈 SEE ALSO 🌈

• Kernel file ./include/linux/device/driver.h — struct device_driver(9)
• driver_find_device_by_name(9)
• driver_find_device_by_of_node(9)
• driver_find_device_by_fwnode(9)
• driver_find_device_by_devt(9)
• driver_find_device_by_acpi_dev(9)
• module_driver(9)
• builtin_driver(9)

and that’s the page, bestie 🎀 it comes from ./include/linux/device and it’s dated October 2026 — mwah 💋✨