RE: Bluetooth USB device keeps same PID/VID after downloading the patch and radio table

Hi Marcel:

It comes out another fix to this one PID/VID issue.
That 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 will increase this value after patch and radio table downloading.
I put the draft modification to the attachment.

Do you think it is possible ?

Thank you very much !

Best Regards,
Steven,

-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
owner@vger.kernel.org] 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:

quoted

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,

quoted

-----Original Message-----
From: Marcel Holtmann [mailto:marcel@holtmann.org]
Sent: Thursday, May 26, 2011 10:47 AM
To: Steven Li
Cc: Gustavo F. Padovan; Bluettooth Linux; Haijun Liu; Hong Fan; Vic Wei;

Jack

quoted

Chen(Taipei); Robert Chang; Luis R. Rodriguez
Subject: Re: Bluetooth USB device keeps same PID/VID after DFU

Hi Steven,

quoted

Here is steven from Atheros.  Glad to contact you here. we have some

concerns to the btusb device driver.

quoted

Present USB Bluetooth implementation in Linux has some limitations.

Many

quoted

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

quoted

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

quoted

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.

quoted

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.

quoted

quoted

Currently, we have three proposals. And I attached our rough patches for

these three proposals.

quoted

They are totally not formal, I attached them just want to make you easy

to

quoted

understand.

quoted

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.

quoted

Mainly, vendor driver would be built as an object of btusb.ko. This should

be same as those UART Bluetooth drivers.

quoted

In our case, ath3k would be built as an object file according to

CONFIG_BT_ATH3K define.

quoted

Then btusb kernel module will be composed of btusb.o and ath3k.o.  So it

is

quoted

easy to make one PID/VID device work.

quoted

This concept was oriented by hci_uart driver.  It can jump to individual

entry function based on different ID.

quoted

And things like mode switch also could be handled by just adding function

like switch_mode() in ath3k.c.

quoted

# 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.

quoted

, and it can first downloads the firmware and then use those functions

exported in btusb driver

quoted

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,

quoted

In the btusb_core.c. It includes all the  Bluetooth usb common operations

and these Bluetooth usb functions will be exported,

quoted

and the btusb_generic.c is the real generic Bluetooth driver remains

support all current Bluetooth device ,which uses the btusb_core functions.

quoted

And vendor driver can also call those usb common operations in the

btusb_core.c.

quoted

With this proposal, Since the ath3k driver are the only owner of the

bluetooth device, only one PID/VID is necessary.

quoted

And it is very easy to handle the mode switch case in itself either. Please

check btusb_ath3k_2.patch for detail.

quoted

# 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.

quoted

http://git.kernel.org/?p=linux/kernel/git/next/linux-

next.git;a=commit;h=cfeb414537b1d7c23ba202f198fa4154cd5a4856

quoted

Vendor specific driver can call btusb_register_quirk_device() function to

register itself to the btusb driver.

quoted

So during the device probe, the btusb will try to match the device id, and

if

quoted

it is a “quirk” device, it will call

quoted

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

quoted

btusb.c.

quoted

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�