Re: use_generic and usb probing

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:
>> http://people.freebsd.org/~avg/usb-use_generic.diff
>>
>> Reviews and testing are welcome.
>>
>> P.S.
>> 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.
> 
> Hi,
> 
> In the initial USB stack design drivers are supposed to either report match or 
> non-match. The reason for this is that sometimes parameters are passed on from 
> 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
nice either.

-- 
Andriy Gapon