Subject: Re: Belkin Bluetooth vs aue vs ubt
To: Jason Thorpe <thorpej@shagadelic.org>
From: Terry Moore <tmm@mcci.com>
List: tech-kern
Date: 03/07/2007 16:28:24
At 01:15 PM 3/7/2007 -0800, Jason Thorpe wrote:

>On Mar 7, 2007, at 1:10 PM, Stephen Borrill wrote:
>
>>On Wed, 7 Mar 2007, Jason Thorpe wrote:
>>>On Mar 7, 2007, at 12:51 PM, Daniel Carosone wrote:
>>>
>>>
>>>>On Wed, Mar 07, 2007 at 12:46:42PM -0800, Jason Thorpe wrote:
>>>
>>>>
>>>>>Should be the other way around!  ubt should avoid matching non-
>>>
>>>>
>>>>>UDPROTO_BLUETOOTH devices!
>>>
>>>>No, that's not the problem - ubt doesn't get a chance because aue
>>>
>>>>grabs the device first (and presumably would also for a real aue
>>>>with
>>>
>>>>the same product id's).
>>>
>>>Uh, no, that's not how autoconfig works.
>>>
>>>Autoconfig, in the direct configuration case (like what USB does)
>>>gives everyone a chance and then takes the highest-priority match
>>>(and if all return the same priority, takes the first one, I think).
>>
>>aue uses:
>>#define UMATCH_VENDOR_PRODUCT                13
>>
>>ubt uses:
>>#define UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO    5
>>
>>So aue will always win.
>
>So either:
>
>- aue should also match against class+subclass+proto first.  It should
>do affirmative matching rather than negative matching.  I.e. "it is an
>Ethernet" as opposed to "it is not a Bluetooth (or a storage device or
>a bar code reader or a mouse or a ...)"
>
>- Matches against against class+subclass+proto should probably match
>higher than vendor+product.  Matches against class+subclass+proto 
>+vendor+product should probably match higher than class+subclass+proto.

For what it's worth, the USB 2.0 spec in chapter 10 explicitly 
specifies that vendor/product matches should take priority over 
class/subclss/proto.  Also, this is what Windows does.

So changing the matching priority within NetBSD is likely to cause 
problems down the road.

It would be better to make the vendor/product match include the revid 
(which is part of chapter 10 rules); Broadcom should have upped the 
revid when they added the class ID.  (I assume from context that the 
problem is that older devices don't have the proper class ID.)

--Terry