on 05/04/2011 14:21 Hans Petter Selasky said the following:
> On Tuesday 05 April 2011 13:06:22 Andriy Gapon wrote:
>> on 03/04/2011 13:46 Andriy Gapon said the following:
>>> Mostly out of curiosity (but not only because of that) I wonder why the
>>> use_generic flag and two probing passes are needed in USB driver probing
>>> code. That is, why the standard approach of using different probing
>>> return values (e.g. BUS_PROBE_DEFAULT, BUS_PROBE_GENERIC, etc) wouldn't
>>> work here.
>> I couldn't find any historic reason for this, so I am assuming that this is
>> a kludge to work-around inconsistent return values in various USB "newbus"
>> probe routines.
>> Please see here my attempt at cleaning up the basics:
>> Reviews and testing are welcome.
>> A side-effect of this patch is removal of a minor annoyance in a form of
>> the following message:
>> Unknown USB device: vendor <> product <> bus <>
>> The message is produced by devd almost any time anything is connected via
>> USB thanks to (1) a nomatch USB entry in the default devd.conf; (2)
>> use_generic=0 probing pass in USB.
> In the initial USB stack design drivers are supposed to either report match
> non-match. The reason for this is that sometimes parameters are passed on
> the probe to the attach via the USB attach args.
> See usbd_lookup_id_by_uaa().
> When multiple drivers are probed and match, the information presented by the
> usb_attach_arg's can get messed up with regard to the attaching driver.
> It would be better if the newbus could support a probing priority argument!
I believe that newbus already supports ordering of children on a bus.
BTW, does USB have to pass anything from probe to attach?
Duplicate lookup is of course not very nice, but duplicate probing pass is not
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"