Better device probe values

[Divacky Roman]

On Tue, Feb 22, 2005 at 02:32:30PM -0700, Warner Losh wrote:
> Greetings,
> 
> >From time to time, the concept of a binary driver has been floated.
> The idea would be that a vendor could put out a binary driver disk
> when there were bugs in the drivers for a specific release so that
> users impacted by those bugs could still, for example, install that
> specific release.
> 
> However, most of the drivers in the base system do not allow this to
> happen because they return 0.
> 
> At the same time, we have a number of generic drivers in the tree that
> have been using ad-hoc values to make sure that the right driver gets
> attached (see for example pci and acpi pci, and friends).  We also
> have some drivers that overlap ranges of devices (eg, ncr and sym
> drivers).
> 
> So, I'd like to standardize on some names, and thought I'd post here
> my first cut at the names.  Let's not get too far off in the weeds,
> since names is a prime bike-shed topic[*].  I'll likely ignore most of
> that part of the discussion, and focus on the more technical and/or
> political side of things.  If possible, I'd like to have this wrapped
> up in time for 5.4, but I do understand that time is extremely short
> for that.
> 
> /**
>  * Some convenience defines for probe routines to return.  These are
>  * just suggested values, and there's nothing magical about them.
>  * BUS_PROBE_SPECIFIC is for devices that cannot be reprobed, and that
>  * no possible other driver may exist (typically legacy drivers who
>  * don't fallow all the rules, or special needs drivers).  BUS_PROBE_VENDOR
>  * is the suggested value that vendor supplied drivers use.  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 is
>  * the normal return value for drivers to use.  It is intended that nearly
>  * all of the drivers in the tree should return this value.
>  * BUS_PROBE_LOW_PRIORITY are for drivers that have 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 is for drivers
>  * that wish to have a generic form and a specialized form, like is done
>  * with the pci bus and that acpi pci bus.  BUS_PROBE_HOOVER is for those
>  * busses that implement a generic device placeholder for devices on the
>  * bus that have no more specific driver for them (aka ugen).
>  */
> #define BUS_PROBE_SPECIFIC	0	/* Only I can use this device */
> #define BUS_PROBE_VEDNOR	(-10)	/* Vendor supplied driver */
                      ^^

typo...