Hi Marcel:
> Hi Steven,
> I deleted your last email by accident. Can you re-send it please.
As you may lose the mail. I'd like to introduce our condition again.
As to the Atheros 3011 chip. yes, it uses DFU mode to download the firmware.
Instead of downloading the firmware, the new Atheros 3012 chip needs to download patch and radio table.
The patch and radio table are used to fix those bugs found after chip shipping or for some other specific use.
And the Atheros 3012 chip itself is a native bluetooth device. Even without downloading patch and radio table, it can work.
So with this design, the Atheros 3012 chip always keeps same PID/VID even after downloading the patch and radio
table. Due to this limitation, we have problems with current btusb.c implementation.
We have to have a work around way, this is to use the bcdDevice (Device Release Number) to judge
whether the Atheros 3012 chip has been patched or not.
The init bcdDevice value of this chip is 0x0001, we can increase this value after patch and radio table downloading.
Do you think it is possible ?
>From 2dc0e703ed392f41d91984b0cfd1da56f6f173cb Mon Sep 17 00:00:00 2001
From: Steven.Li <Steven.Li@xxxxxxxxxxx>
Date: Thu, 26 May 2011 17:06:52 +0800
Subject: [PATCH] Use bcdDevice(Device Release Number) to exclude the ath3k and btusb driver.
---
drivers/bluetooth/ath3k.c | 5 ++++-
drivers/bluetooth/btusb.c | 9 ++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 6bacef3..c99fb08 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -375,6 +375,9 @@ static int ath3k_probe(struct usb_interface *intf,
/* load patch and sysconfig files for AR3012 */
if (id->driver_info & BTUSB_ATH3012) {
+ if(le16_to_cpu(udev->descriptor.bcdDevice > 0x0001))
+ return -ENODEV;
+
ret = ath3k_load_patch(udev);
if (ret < 0) {
BT_ERR("Loading patch file failed");
@@ -390,7 +393,7 @@ static int ath3k_probe(struct usb_interface *intf,
BT_ERR("Set normal mode failed");
return ret;
}
- ath3k_switch_pid(udev);
+ /* ath3k_switch_pid(udev); */
return 0;
}
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c2de895..9b67b22 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -54,6 +54,7 @@ static struct usb_driver btusb_driver;
#define BTUSB_BCM92035 0x10
#define BTUSB_BROKEN_ISOC 0x20
#define BTUSB_WRONG_SCO_MTU 0x40
+#define BTUSB_ATH3012 0x80
static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
@@ -110,7 +111,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
/* Atheros 3012 with sflash firmware */
- { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_IGNORE },
+ { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
@@ -914,6 +915,12 @@ static int btusb_probe(struct usb_interface *intf,
if (ignore_sniffer && id->driver_info & BTUSB_SNIFFER)
return -ENODEV;
+ if (id->driver_info & BTUSB_ATH3012) {
+ struct usb_device *udev = interface_to_usbdev(intf);
+ if(le16_to_cpu(udev->descriptor.bcdDevice <= 0x0001))
+ return -ENODEV;
+ }
+
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
--
1.7.1
Thank you very much !
Best Regards,
Steven,
> -----Original Message-----
> From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Steven Li
> Sent: Thursday, May 26, 2011 4:46 PM
> To: Marcel Holtmann
> Cc: Gustavo F. Padovan; Bluettooth Linux; Haijun Liu; Hong Fan; Vic Wei; Jack
> Chen(Taipei); Robert Chang; Luis R. Rodriguez
> Subject: RE: Bluetooth USB device keeps same PID/VID after downloading
> the patch and radio table
>
> Hi Marcel:
>
> > why do you want this at all. You run a different protocol with different
> > endpoints on the device in DFU mode and on the device in H:2 mode.
>
> Sorry, I made a mistake in the subject of this mail thread.
> The "Bluetooth USB device keeps same PID/VID after DFU".
> should be " Bluetooth USB device keeps same PID/VID after downloading
> the patch and radio table".
>
> As to the Atheros 3011 chip. yes, it uses DFU mode to download the
> firmware.
> So there are different protocols with different endpoints on the device.
>
> But now, we are going to upstream our new Atheros 3012 chip and things are
> not like that.
> The Atheros 3012 chip is a native bluetooth device, even without
> downloading patch and radio table.
> The patch and radio table are used to fix those bugs found after chip shipping.
> So with this design, the Atheros 3012 chip
> always keeps same PID/VID even after downloading the patch and radio
> table.
>
> That comes out our concern to the btusb driver.
>
>
>
> Best Regards,
> Steven,
>
>
> > -----Original Message-----
> > From: Marcel Holtmann [mailto:marcel@xxxxxxxxxxxx]
> > Sent: Thursday, May 26, 2011 10:47 AM
> > To: Steven Li
> > Cc: Gustavo F. Padovan; Bluettooth Linux; Haijun Liu; Hong Fan; Vic Wei;
> Jack
> > Chen(Taipei); Robert Chang; Luis R. Rodriguez
> > Subject: Re: Bluetooth USB device keeps same PID/VID after DFU
> >
> > Hi Steven,
> >
> > > Here is steven from Atheros. Glad to contact you here. we have some
> > concerns to the btusb device driver.
> > > Present USB Bluetooth implementation in Linux has some limitations.
> Many
> > vendors need to load patch and other specific operations during device
> > probe or disconnect to their Bluetooth device, but btusb driver gives
> > limitation to this behavior. It needs to add the Bluetooth device PID/VID
> into
> > the btusb blacklist, and use the vendor specific driver to load firmware. By
> > this, it causes the Bluetooth device "MUST" have two PID/VIDs in Linux.
> But
> > on windows platform, the device can always keep one same PID/VID. It is
> > hard for us to handle this issue with current btusb design.
> > > Moreover in our Atheros 3012 chip, we also need to switch the 3012 chip
> > between "normal" mode and "pre-boot" mode during PC reboot, with
> > current btusb design, we have to make changes in btusb.c directly, but it is
> > our chip specific requirements. Therefore, weâd like to propose some
> > methods to make the Bluetooth device has only one PID/VID by proper
> > btusb modification and also for other vendor extensions such as mode
> switch.
> > >
> > > Currently, we have three proposals. And I attached our rough patches for
> > these three proposals.
> > > They are totally not formal, I attached them just want to make you easy
> to
> > understand.
> > >
> > > And from here, Let me explain more of these proposal one by one.
> > >
> > > # Proposal 1.
> > > This option could be refer to what itâs working for lots of UART Bluetooth
> > devices in Linux.
> > > Mainly, vendor driver would be built as an object of btusb.ko. This should
> > be same as those UART Bluetooth drivers.
> > > In our case, ath3k would be built as an object file according to
> > CONFIG_BT_ATH3K define.
> > > Then btusb kernel module will be composed of btusb.o and ath3k.o. So it
> is
> > easy to make one PID/VID device work.
> > > This concept was oriented by hci_uart driver. It can jump to individual
> > entry function based on different ID.
> > > And things like mode switch also could be handled by just adding function
> > like switch_mode() in ath3k.c.
> > >
> > > # Proposal 2.
> > > This option is to export btusb common functions, and vendor driver (for
> > example our ath3k) can be taken as the extension of btusb.
> > > , and it can first downloads the firmware and then use those functions
> > exported in btusb driver
> > > to setup the hci Bluetooth device. Moreover if it is possible, we are also
> > propose to refine the btusb.c and split the btusb.c to btusb_core.c and
> > btusb_generic.c,
> > > In the btusb_core.c. It includes all the Bluetooth usb common operations
> > and these Bluetooth usb functions will be exported,
> > > and the btusb_generic.c is the real generic Bluetooth driver remains
> > support all current Bluetooth device ,which uses the btusb_core functions.
> > > And vendor driver can also call those usb common operations in the
> > btusb_core.c.
> > > With this proposal, Since the ath3k driver are the only owner of the
> > bluetooth device, only one PID/VID is necessary.
> > > And it is very easy to handle the mode switch case in itself either. Please
> > check btusb_ath3k_2.patch for detail.
> > >
> > > # Proposal 3.
> > > This option is to add "quirk device" to btusb driver. We found actually you
> > added lots of so-called âquirkâ implementation in btusb driver for many
> > vendors.
> > > http://git.kernel.org/?p=linux/kernel/git/next/linux-
> > next.git;a=commit;h=cfeb414537b1d7c23ba202f198fa4154cd5a4856
> > > Vendor specific driver can call btusb_register_quirk_device() function to
> > register itself to the btusb driver.
> > > So during the device probe, the btusb will try to match the device id, and
> if
> > it is a âquirkâ device, it will call
> > > the âquirkâ deviceâs specific function first. Every vendor can use this quirk
> > to download their firmware and keep the same PID/VID with proper codes
> in
> > btusb.c.
> > > This proposal is also able to handle the mode switch case.
> > >
> > > Please give your comments and suggestion for our proposals.
> > > We are hoping to make one PID/VID work and contribute to the
> > community.
> >
> > why do you want this at all. You run a different protocol with different
> > endpoints on the device in DFU mode and on the device in H:2 mode.
> >
> > So you actually have different functionality. And I personally do not
> > care what Windows is doing. This is Linux, so please follow what the
> > Linux community expect you to do.
> >
> > Also in case of btusb, you can use the Bluetooth SIG (and for that
> > matter USB SIG) defined interface identifiers. The btusb driver does not
> > match by default to VID/PID. It uses a standard. If you wanna use the
> > same VID/PID here, then declare the interface identifiers properly and
> > everything would work out nicely.
> >
> > You guys insist on lying to the USB subsystem and by that fact most
> > likely violating the USB standards. Don't do that and everything will
> > work out of the box with Linux. No extra patches or modification for
> > btusb needed.
> >
> > Regards
> >
> > Marcel
> >
>
> ï{.nï+ïïïïïïï+%ïïlzwmïïbïëïïrïïzXïïïïhïïbïï^nïrïïïzïïïhï
> ïïï&ïï ïGïïïhï(ïéïÝj"ïïïmïïïïïzïÞïïïfïïïhïïï~ïmï
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
