Manual Reference Pages - DEVICE_PROBE (9)
- probe for device existence
DEVICE_PROBE device_t dev
method should probe to see if the device is present.
It should return 0 if the device exists,
if it cannot be found.
If some other error happens during the probe (such as a memory
allocation failure), an appropriate error code should be returned.
cases where more than one driver matches a device, a priority value can
In this case, success codes are values less than or equal
to zero with the highest value representing the best match.
codes are represented by positive values and the regular
codes should be used for the purpose.
If a driver returns a success code which is less than zero, it must
not assume that it will be the same driver which is attached to the
In particular, it must not assume that 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.
In addition it is an absolute requirement that the probe routine have
no side effects whatsoever.
The probe routine may be called more than once before the attach
routine is called.
If a success code of zero is
returned, the driver can assume that it will be the one attached, but
must not hold any resources when the probe routine returns.
A driver may assume that the softc is preserved when it returns
a success code of zero.
A value equal to or less than zero indicates success, greater than
zero indicates an error (errno).
For values equal to or less than
zero: zero indicates highest priority, no further probing is done;
for a value less than zero, the lower the value the lower the
priority, e.g. -100 indicates a lower priority than -50.
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 theres nothing
magical about them.
The device that cannot be reprobed, and that no
possible other driver may exist (typically legacy drivers who dont follow
all the rules, or special needs drivers).
The device is supported by a vendor driver.
This is for source or binary drivers that are not yet integrated into the
Its use in the base OS is prohibited.
The device is a normal device matching some plug and play ID. This is
the normal return value for drivers to use.
It is intended that nearly all of the drivers in the tree should return
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
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.
The driver matches all unclaimed devices on a bus.
device is one example.
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 manual page was written by
.An Doug Rabson .
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.