[Raring][PATCH] UBUNTU: SAUCE: Bluetooth: use hci_send_cmd instead of usb_control_msg

[Jesse Sung]

2013/9/6 Tim Gardner <tim.gardner at canonical.com>:
> More comments below...
>
> On 09/04/2013 10:42 AM, Jesse Sung wrote:
>> From: Wen-chien Jesse Sung <jesse.sung at canonical.com>
>>
>> BugLink: https://launchpad.net/bugs/1065400
>>
>> Calling usb_control_msg directly to send firmware file does not work
>> with new platforms. Use hci_send_cmd instead.
>>
>> Signed-off-by: Wen-chien Jesse Sung <jesse.sung at canonical.com>
>> ---
>>  drivers/bluetooth/btusb.c | 58 +++++++++++++++++++++++------------------------
>>  net/bluetooth/hci_core.c  |  1 +
>>  2 files changed, 29 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index 5be9002..3a82e09 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -49,7 +49,7 @@ static struct usb_driver btusb_driver;
>>  #define BTUSB_BROKEN_ISOC    0x20
>>  #define BTUSB_WRONG_SCO_MTU  0x40
>>  #define BTUSB_ATH3012                0x80
>> -#define BTUSB_BCM_PATCHRAM   0x100
>> +#define BTUSB_BCM_PATCHRAM   0x800
>>
>>  static struct usb_device_id btusb_table[] = {
>>       /* Generic Bluetooth USB device */
>> @@ -226,14 +226,13 @@ static struct usb_device_id blacklist_table[] = {
>>  #define BTUSB_ISOC_RUNNING   2
>>  #define BTUSB_SUSPENDING     3
>>  #define BTUSB_DID_ISO_RESUME 4
>> -#define BTUSB_FIRMWARE_DONE  5
>> +#define BTUSB_FIRMWARE_DONE  7
>>
>>  struct btusb_data {
>>       struct hci_dev       *hdev;
>>       struct usb_device    *udev;
>>       struct usb_interface *intf;
>>       struct usb_interface *isoc;
>> -     const struct usb_device_id *id;
>>
>>       spinlock_t lock;
>>
>> @@ -938,24 +937,20 @@ static void btusb_waker(struct work_struct *work)
>>       usb_autopm_put_interface(data->intf);
>>  }
>>
>> -#define PATCHRAM_TIMEOUT     1000
>>  #define PATCHRAM_NAME_LEN    20
>> +#define PATCHRAM_BUF_SIZE    (256 + 4)
>>
>>  static void btusb_load_firmware(struct hci_dev *hdev)
>>  {
>>       struct btusb_data *data = hci_get_drvdata(hdev);
>>       struct usb_device *udev = data->udev;
>> -     const struct usb_device_id *id = data->id;
>>       size_t pos = 0;
>>       int err = 0;
>>       char filename[PATCHRAM_NAME_LEN];
>>       const struct firmware *fw;
>> +     u8 *buf = NULL;
>> +     u8 val = 0;
>>
>> -     unsigned char reset_cmd[] = { 0x03, 0x0c, 0x00 };
>> -     unsigned char download_cmd[] = { 0x2e, 0xfc, 0x00 };
>> -
>> -     if (!(id->driver_info & BTUSB_BCM_PATCHRAM))
>> -             return;
>
> If you remove these 2 lines then it seems that all Bluetooth adapters
> will get the PATCHRAM treatment, regardless of the quirk setting in
> btusb_table[].

Detection is moved to probe(), thus there's no need to save id in
private data anymore.

-       hdev->load_firmware = btusb_load_firmware;
+
+       if (id->driver_info & BTUSB_BCM_PATCHRAM)
+               hdev->load_firmware = btusb_load_firmware;

> Have you done any regression testing on Bluetooth adapters that don't
> require PATCHRAM support ?

Yes, tested with a 0a5c:2145 and it works.

T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a5c ProdID=2145 Rev=03.99
S:  Manufacturer=Lenovo Computer Corp
S:  Product=ThinkPad Bluetooth with Enhanced Data Rate II
C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)

Thanks,
Jesse