Return-path: Received: from mail.atheros.com ([12.19.149.2]:34551 "EHLO mail.atheros.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753348Ab0JFQiS (ORCPT ); Wed, 6 Oct 2010 12:38:18 -0400 Date: Wed, 6 Oct 2010 09:38:16 -0700 From: "Luis R. Rodriguez" To: Marcel Holtmann CC: Luis Rodriguez , linux-bluetooth , "linux-kernel@vger.kernel.org" , "linux-wireless@vger.kernel.org" , Deepak Dhamdhere , Sree Durbha Subject: Re: RFC: btusb firmware load help Message-ID: <20101006163816.GE7070@tux> References: <20100924230730.GB6566@tux> <1286266981.17473.33.camel@aeonflux> <20101005192814.GB11831@tux> <1286308731.2588.13.camel@aeonflux> <1286349552.6145.11.camel@aeonflux> <1286380566.6145.42.camel@aeonflux> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <1286380566.6145.42.camel@aeonflux> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Oct 06, 2010 at 08:56:06AM -0700, Marcel Holtmann wrote: > Hi Luis, > > > > Now I am failing to understand why this was done wrong in the first > > > place. Especially if the loading procedure happens as you say it > > > happens. > > > > You got me :) Anyone? > > > > > This is the example for the Broadcom 203x devices: > > > > > > static struct usb_device_id blacklist_table[] = { > > > /* Broadcom BCM2033 without firmware */ > > > { USB_DEVICE(0x0a5c, 0x2033), .driver_info = BTUSB_IGNORE }, > > > > > > The btusb driver clearly blacklists them. And then bcm203x can take over > > > loading the firmware: > > > > > > static const struct usb_device_id bcm203x_table[] = { > > > /* Broadcom Blutonium (BCM2033) */ > > > { USB_DEVICE(0x0a5c, 0x2033) }, > > > > > > So there is a working example of this already in the kernel tree since > > > forever. > > > > Nice, thanks for the pointer. Our team will review and try to address > > an alternative patch. > > > > Now for my own sanity -- I still don't think I get this how this > > BCM2033 blacklist trick works, I take it the device once plugged in > > gets a generic btusb USB device vendor:device ID. The btusb driver > > then picks up the the blacklist table, and searches for a > > usb_match_id() on it for the given interface... What I don't get is > > how there will be a match here if the USB vendor:device ID is just the > > generic btusb one. Can you help me understand how this trick works? > > the generic Bluetooth USB class descriptors is what btusb uses. With a > few expectation for devices that use VID:PID combination. Ahhh... got it.. > So in general what happens if a device gets matched via the Bluetooth > USB class descriptors the btusb driver will claim. We do however check > against out blacklist first. If the VID:PID is listed in the blacklist > we do return ENODEV. That means that the USB subsystem goes ahead and > tries the next driver. In this case bcm203x driver. This will claim it, > load the firmware, reset it and come back with different VID:PID values. > After that the btusb can successfully claim it since it is no longer in > the blacklist. Ah neat. > If I understand this all correct without having the hardware available > for verifying this, then it should be like this: > > Just add this to blacklist_table[] in btusb.c: > > /* Atheros AR3011 without firmware */ > { USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE }, > > And then we can add the firmware loading to ath3k driver to load the > specific 1st stage firmware. And then ath3k can load the 2nd stage as > well. After that it should become a default Bluetooth USB device and the > btusb driver can take care of it. Got it... thanks for the clarification. So ath3k actually doesn't seem to have 2-stage firmware files, ath3k-2.fw actually seems to be a new firmware upgrade. The firmware already made it into linux-firmware.git tree but the respective patch just never made it upstream. I am not sure of the differences between these firmware but I do remember reading from Vikram that no new API was changed. I asked for clarification on the firmware updates and asked if it can be documented here: http://wireless.kernel.org/en/users/Drivers/ath3k If the device can live with simply getting ath3k-1.fw loaded once then perhaps the change you described above is all that is needed, not sure. Deepak, can you please try this patch, I don't have hardware to test this with. diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index d22ce3c..a62c1b2 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -140,6 +140,9 @@ static struct usb_device_id blacklist_table[] = { /* Frontline ComProbe Bluetooth Sniffer */ { USB_DEVICE(0x16d3, 0x0002), .driver_info = BTUSB_SNIFFER }, + /* Atheros AR3011 without firmware */ + { USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE }, + { } /* Terminating entry */ };