http://www.freebsd.org/cgi/man.cgi?query=DEVICE_PROBE&apropos=0&sektion=0&manpath=FreeBSD%208.2-RELEASE&format=html
DEVICE_PROBE(9) has this to say about 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. I interpreted this as meaning that if BUS_ADD_CHILD() is called with the name parameter specifying a driver then if that driver's probe method returns BUS_PROBE_NOWILDCARD the driver will match that device. However the logic in subr_bus.c is more strict; it will only match if the unit number if also specified. This seems overly strict to me, and there appears to be at least one case in-tree where a driver will never match due to this behaviour: http://svnweb.freebsd.org/base/head/sys/dev/iicbus/iicsmb.c?revision=227843&view=markup The iicsmb driver calls BUS_ADD_CHILD() from its identify method with a wildcarded unit number (-1) but the driver specified. It then returns BUS_PROBE_NOWILDCARD from its attach method(intending that it only claim the device created in the identify method), but that won't match. I want to use the exact same pattern in a new driver. The following patch allows this to work: diff --git a/sys/kern/subr_bus.c b/sys/kern/subr_bus.c index 1f3d4e8..7e48b0e 100644 --- a/sys/kern/subr_bus.c +++ b/sys/kern/subr_bus.c @@ -2015,7 +2015,7 @@ device_probe_child(device_t dev, device_t child) * in stone by the parent bus. */ if (result <= BUS_PROBE_NOWILDCARD && - child->flags & DF_WILDCARD) + !(child->flags & DF_FIXEDCLASS)) continue; best = dl; pri = result; This should be safe to do, as all devices that specified a unit number must have specified a driver, so this can't cause any devices to suddenly fail to match. I supposed that it theoretically could cause a driver to match a device that previously it wouldn't have, but I'm having trouble seeing how somebody could add a device of type "foo" and not expect the "foo" driver to attach. Any objections if I commit this? _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
