Subject: Re: Belkin Bluetooth vs aue vs ubt
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Stephen Borrill <netbsd@precedence.co.uk>
List: tech-kern
Date: 03/09/2007 08:48:09
On Thu, 8 Mar 2007, Matthias Drochner wrote:
> M.Drochner@fz-juelich.de said:
>> if_aue.c:
>> 	if (uaa->iface != NULL)
>> 		return (UMATCH_NONE);
>> That's actually a bug in that driver as I see it. It should work as
>> well with an "==" at that point.
>
> Sorry, I confused this with another driver I'm having issues with.
> The "aue" driver is correct. (Within the limits of the framework.)
> Actually it doesn't matter at all...
>
> To explain some more: USB driver attachment currently works as follows.
> 1. The device is not configured (in terms of USB), and aa->iface is NULL.
>   A round of driver matches is done.
> 2. The framework selects a configuration (in theory one of multiple
>   possibilities, but none of my devices has more than one). A configuration
>   may consist if multiple interfaces.
>   For each interfaces, aa->iface is set to it, and another round of
>   driver matches is done.
>
> This is pretty weak, and allows drivers to get away with all kinds
> of misbehaviour.

So what's the solution in this case?

I've had a couple of aue testers look at this and the device class for a 
genuine aue is UDCLASS_IN_INTERFACE, but we can't use the class 
information in the Interface Descriptors because we've already returned 
with UMATCH_NONE if there is an interface set up!

However, I don't think we need to be too fastidious about this. How about:

dd = usbd_get_device_descriptor(uaa->device);
if (dd != NULL &&
 	dd->bDeviceClass != UDCLASS_COMM &&
 	dd->bDeviceClass != UDCLASS_IN_INTERFACE)
                 return (UMATCH_NONE);

-- 
Stephen