DEVICE_PROBE(9)

💅 DEVICE_PROBE 💅

okay so bestie, welcome to the DEVICE_PROBE(9) page from the Kernel Developer's Manual — this is the one that tells you how to probe for device existence, and honestly it's giving main character energy in the whole driver-matching saga 🎀

---

🌸 SYNOPSIS 🌸

#include <sys/param.h>
#include <sys/bus.h>

int
DEVICE_PROBE(device_t dev);

like, that's the whole vibe check right there ✨

---

💖 DESCRIPTION 💖

okay so DEVICE_PROBE() is the method that should, like, probe to see if the device is actually there. super straightforward.

• it returns 0 if the device exists
• it returns ENXIO if it cannot be found

and if some other error happens during the probe (think: a memory allocation failure 😭), it should return an appropriate error code. no cap.

now here's the fun part — when more than one driver matches a device, you can return a priority value instead. in that case:

• success codes are values less than or equal to zero, and the highest value is the best match 👑
• failure codes are positive values, and you should use the regular Unix error codes for that purpose, iykyk

🫶 okay so important caveat time: if a driver returns a success code that's less than zero, it must not assume it'll be the same driver attached to the device. like, specifically, it must not assume any values stored in the softc structure will be available for its attach method, and any resources allocated during probe must be released and re-allocated if the attach method is called. also — and this is an absolute requirement — the probe routine must have no side effects whatsoever. the probe routine may be called more than once before the attach routine is called. 💀

but!! if a success code of zero is returned, the driver can assume it'll be the one attached — it just must not hold any resources when the probe routine returns. and a driver may assume the softc is preserved when it returns a success code of zero ✨

---

⭐ RETURN VALUES ⭐

quick recap bestie:

• a value equal to or less than zero = success 🎉
• greater than zero = an error (errno)
• for values equal to or less than zero: 0 = highest priority, and no further probing is done
• for a value less than zero: the lower the value, the lower the priority — so like, -100 indicates a lower priority than -50. math! 🧮

the following values are used by convention to indicate different strengths of matching in a probe routine. except as noted, these are just suggested values, and there's nothing magical about them 🔮

• BUS_PROBE_SPECIFIC — the device that cannot be reprobed, and that no possible other driver may exist (typically legacy drivers who don't follow all the rules, or special needs drivers).
• BUS_PROBE_VENDOR — the device is supported by a vendor driver. this is for source or binary drivers that are not yet integrated into the FreeBSD tree. its use in the base OS is prohibited 🚫.
• BUS_PROBE_DEFAULT — the device is a normal device matching some plug and play ID. this is the normal return value for drivers to use. it's intended that nearly all of the drivers in the tree should return this value 🫶.
• BUS_PROBE_LOW_PRIORITY — the driver is a legacy driver, or an otherwise less desirable driver for a given plug and play ID. the driver has special requirements like when there are two drivers that support overlapping series of hardware devices. in this case the one that supports the older part of the line would return this value, while the one that supports the newer ones would return BUS_PROBE_DEFAULT 🌈.
• BUS_PROBE_GENERIC — the driver matches the type of device generally. this allows drivers to match all serial ports generally, with specialized drivers matching particular types of serial ports that need special treatment for some reason.
• BUS_PROBE_HOOVER — the driver matches all unclaimed devices on a bus. the ugen(4) device is one example 🧹.
• BUS_PROBE_NOWILDCARD — the driver expects its parent to tell it which children to manage and no probing is really done. the device only matches if its parent bus specifically said to use this driver.

---

🦋 SEE ALSO 🦋

device(9), DEVICE_ATTACH(9), DEVICE_DETACH(9), DEVICE_IDENTIFY(9), DEVICE_SHUTDOWN(9)

---

👑 AUTHORS 👑

this manual page was written by Doug Rabson 💜

---

and that's the whole page bestie, slay 💅 — this lil gem comes to you from the Debian edition, dated February 8, 2012, and it's literally the DEVICE_PROBE(9) page of the Kernel Developer's Manual. go forth and probe responsibly ✨🎀🦋