[PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Li, Steven]

The new Ath3k needs to download patch and radio table,
and it keeps same PID/VID even after downloading the patch and radio table.
This patch is to use the bcdDevice (Device Release Number) to judge whether the
chip has been patched or not. The init bcdDevice value of the chip is 0x0001,
this value increases after patch and radio table downloading.

Signed-off-by: Steven.Li <yongli@qca.qualcomm.com>
---
 drivers/bluetooth/ath3k.c |    3 +++
 drivers/bluetooth/btusb.c |    9 ++++++++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 6bacef3..7ae1098 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");
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index c2de895..9d01e25 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

Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Marcel Holtmann]

Hi Steven,

> The new Ath3k needs to download patch and radio table,
> and it keeps same PID/VID even after downloading the patch and radio table.
> This patch is to use the bcdDevice (Device Release Number) to judge whether the
> chip has been patched or not. The init bcdDevice value of the chip is 0x0001,
> this value increases after patch and radio table downloading.
> 
> Signed-off-by: Steven.Li <yongli@qca.qualcomm.com>
> ---
>  drivers/bluetooth/ath3k.c |    3 +++
>  drivers/bluetooth/btusb.c |    9 ++++++++-
>  2 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
> index 6bacef3..7ae1098 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;
> +

please fix the coding style. It is if[space](.

Also you might wanna put a comment on top of this bcdDevice check and
mention what it actually does.

>  		ret = ath3k_load_patch(udev);
>  		if (ret < 0) {
>  			BT_ERR("Loading patch file failed");
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index c2de895..9d01e25 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;
> +	}

Coding style fix as well please. I would say something similar in style
to what I have done for the older CSR chips. See workaround above.

And on that note, you could use data->udev to get the usb_device
struct ;)

Regards

Marcel

RE: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Li, Steven]

SGkgTWFyY2VsOg0KDQo+IHBsZWFzZSBmaXggdGhlIGNvZGluZyBzdHlsZS4gSXQgaXMgaWZbc3Bh
Y2VdKC4NCk9rYXksIEkgc2VlLg0KDQo+IEkgd291bGQgc2F5IHNvbWV0aGluZyBzaW1pbGFyIGlu
IHN0eWxlDQo+IHRvIHdoYXQgSSBoYXZlIGRvbmUgZm9yIHRoZSBvbGRlciBDU1IgY2hpcHMuIFNl
ZSB3b3JrYXJvdW5kIGFib3ZlLg0KPiBBbmQgb24gdGhhdCBub3RlLCB5b3UgY291bGQgdXNlIGRh
dGEtPnVkZXYgdG8gZ2V0IHRoZSB1c2JfZGV2aWNlDQo+IHN0cnVjdCA7KQ0KQXMgdG8gdGhpcyBw
b2ludCwgIHNpbmNlIG5vdyB3ZSBhcmUgbm90IHVzaW5nIHRoZSBidHVzYiB0byBkb3dubG9hZCB0
aGUgcGF0Y2ggYW5kIHJhZGlvIHRhYmxlLA0KIEkgdGhpbmsgd2UgZG8gbm90IG5lZWQgdG8gYWxs
b2MgdGhlIGRhdGEgc3RydWN0IGFuZCB1c2UgZGF0YS0+dWRldiBiZWZvcmUgdGhlIHdvcmthcm91
bmQuICANClNvIEknbGwgc3RpbGwga2VlcCBpdCB3YXMuICBIb3cgZG8geW91IHRoaW5rIGl0ID8N
Cg0KDQpUaGFuayB5b3UgdmVyeSBtdWNoICENCg0KQmVzdCBSZWdhcmRzLA0KU3RldmVuLA0KDQoN
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFyY2VsIEhvbHRtYW5uIFtt
YWlsdG86bWFyY2VsQGhvbHRtYW5uLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDI5LCAy
MDExIDg6NTEgQU0NCj4gVG86IExpLCBTdGV2ZW4NCj4gQ2M6IGxpbnV4LWJsdWV0b290aEB2Z2Vy
Lmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gQmx1ZXRvb3RoOiBBdGgzayBrZWVw
cyBzYW1lIFBJRC9WSUQgYWZ0ZXINCj4gZG93bmxvYWRpbmcgdGhlIHBhdGNoIGFuZCByYWRpbyB0
YWJsZQ0KPiANCj4gSGkgU3RldmVuLA0KPiANCj4gPiBUaGUgbmV3IEF0aDNrIG5lZWRzIHRvIGRv
d25sb2FkIHBhdGNoIGFuZCByYWRpbyB0YWJsZSwNCj4gPiBhbmQgaXQga2VlcHMgc2FtZSBQSUQv
VklEIGV2ZW4gYWZ0ZXIgZG93bmxvYWRpbmcgdGhlIHBhdGNoIGFuZCByYWRpbw0KPiB0YWJsZS4N
Cj4gPiBUaGlzIHBhdGNoIGlzIHRvIHVzZSB0aGUgYmNkRGV2aWNlIChEZXZpY2UgUmVsZWFzZSBO
dW1iZXIpIHRvIGp1ZGdlDQo+IHdoZXRoZXIgdGhlDQo+ID4gY2hpcCBoYXMgYmVlbiBwYXRjaGVk
IG9yIG5vdC4gVGhlIGluaXQgYmNkRGV2aWNlIHZhbHVlIG9mIHRoZSBjaGlwIGlzIDB4MDAwMSwN
Cj4gPiB0aGlzIHZhbHVlIGluY3JlYXNlcyBhZnRlciBwYXRjaCBhbmQgcmFkaW8gdGFibGUgZG93
bmxvYWRpbmcuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBTdGV2ZW4uTGkgPHlvbmdsaUBxY2Eu
cXVhbGNvbW0uY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL2JsdWV0b290aC9hdGgzay5jIHwg
ICAgMyArKysNCj4gPiAgZHJpdmVycy9ibHVldG9vdGgvYnR1c2IuYyB8ICAgIDkgKysrKysrKyst
DQo+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkN
Cj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2JsdWV0b290aC9hdGgzay5jIGIvZHJpdmVy
cy9ibHVldG9vdGgvYXRoM2suYw0KPiA+IGluZGV4IDZiYWNlZjMuLjdhZTEwOTggMTAwNjQ0DQo+
ID4gLS0tIGEvZHJpdmVycy9ibHVldG9vdGgvYXRoM2suYw0KPiA+ICsrKyBiL2RyaXZlcnMvYmx1
ZXRvb3RoL2F0aDNrLmMNCj4gPiBAQCAtMzc1LDYgKzM3NSw5IEBAIHN0YXRpYyBpbnQgYXRoM2tf
cHJvYmUoc3RydWN0IHVzYl9pbnRlcmZhY2UgKmludGYsDQo+ID4NCj4gPiAgCS8qIGxvYWQgcGF0
Y2ggYW5kIHN5c2NvbmZpZyBmaWxlcyBmb3IgQVIzMDEyICovDQo+ID4gIAlpZiAoaWQtPmRyaXZl
cl9pbmZvICYgQlRVU0JfQVRIMzAxMikgew0KPiA+ICsJCWlmKGxlMTZfdG9fY3B1KHVkZXYtPmRl
c2NyaXB0b3IuYmNkRGV2aWNlKSA+IDB4MDAwMSkNCj4gPiArCQkJcmV0dXJuIC1FTk9ERVY7DQo+
ID4gKw0KPiANCj4gcGxlYXNlIGZpeCB0aGUgY29kaW5nIHN0eWxlLiBJdCBpcyBpZltzcGFjZV0o
Lg0KPiANCj4gQWxzbyB5b3UgbWlnaHQgd2FubmEgcHV0IGEgY29tbWVudCBvbiB0b3Agb2YgdGhp
cyBiY2REZXZpY2UgY2hlY2sgYW5kDQo+IG1lbnRpb24gd2hhdCBpdCBhY3R1YWxseSBkb2VzLg0K
PiANCj4gPiAgCQlyZXQgPSBhdGgza19sb2FkX3BhdGNoKHVkZXYpOw0KPiA+ICAJCWlmIChyZXQg
PCAwKSB7DQo+ID4gIAkJCUJUX0VSUigiTG9hZGluZyBwYXRjaCBmaWxlIGZhaWxlZCIpOw0KPiA+
IGRpZmYgLS1naXQgYS9kcml2ZXJzL2JsdWV0b290aC9idHVzYi5jIGIvZHJpdmVycy9ibHVldG9v
dGgvYnR1c2IuYw0KPiA+IGluZGV4IGMyZGU4OTUuLjlkMDFlMjUgMTAwNjQ0DQo+ID4gLS0tIGEv
ZHJpdmVycy9ibHVldG9vdGgvYnR1c2IuYw0KPiA+ICsrKyBiL2RyaXZlcnMvYmx1ZXRvb3RoL2J0
dXNiLmMNCj4gPiBAQCAtNTQsNiArNTQsNyBAQCBzdGF0aWMgc3RydWN0IHVzYl9kcml2ZXIgYnR1
c2JfZHJpdmVyOw0KPiA+ICAjZGVmaW5lIEJUVVNCX0JDTTkyMDM1CQkweDEwDQo+ID4gICNkZWZp
bmUgQlRVU0JfQlJPS0VOX0lTT0MJMHgyMA0KPiA+ICAjZGVmaW5lIEJUVVNCX1dST05HX1NDT19N
VFUJMHg0MA0KPiA+ICsjZGVmaW5lIEJUVVNCX0FUSDMwMTIJCTB4ODANCj4gPg0KPiA+ICBzdGF0
aWMgc3RydWN0IHVzYl9kZXZpY2VfaWQgYnR1c2JfdGFibGVbXSA9IHsNCj4gPiAgCS8qIEdlbmVy
aWMgQmx1ZXRvb3RoIFVTQiBkZXZpY2UgKi8NCj4gPiBAQCAtMTEwLDcgKzExMSw3IEBAIHN0YXRp
YyBzdHJ1Y3QgdXNiX2RldmljZV9pZCBibGFja2xpc3RfdGFibGVbXSA9IHsNCj4gPiAgCXsgVVNC
X0RFVklDRSgweDAzZjAsIDB4MzExZCksIC5kcml2ZXJfaW5mbyA9IEJUVVNCX0lHTk9SRSB9LA0K
PiA+DQo+ID4gIAkvKiBBdGhlcm9zIDMwMTIgd2l0aCBzZmxhc2ggZmlybXdhcmUgKi8NCj4gPiAt
CXsgVVNCX0RFVklDRSgweDBjZjMsIDB4MzAwNCksIC5kcml2ZXJfaW5mbyA9IEJUVVNCX0lHTk9S
RSB9LA0KPiA+ICsJeyBVU0JfREVWSUNFKDB4MGNmMywgMHgzMDA0KSwgLmRyaXZlcl9pbmZvID0g
QlRVU0JfQVRIMzAxMiB9LA0KPiA+DQo+ID4gIAkvKiBBdGhlcm9zIEFSNUJCVTEyIHdpdGggc2Zs
YXNoIGZpcm13YXJlICovDQo+ID4gIAl7IFVTQl9ERVZJQ0UoMHgwNDg5LCAweGUwMmMpLCAuZHJp
dmVyX2luZm8gPSBCVFVTQl9JR05PUkUgfSwNCj4gPiBAQCAtOTE0LDYgKzkxNSwxMiBAQCBzdGF0
aWMgaW50IGJ0dXNiX3Byb2JlKHN0cnVjdCB1c2JfaW50ZXJmYWNlICppbnRmLA0KPiA+ICAJaWYg
KGlnbm9yZV9zbmlmZmVyICYmIGlkLT5kcml2ZXJfaW5mbyAmIEJUVVNCX1NOSUZGRVIpDQo+ID4g
IAkJcmV0dXJuIC1FTk9ERVY7DQo+ID4NCj4gPiArCWlmIChpZC0+ZHJpdmVyX2luZm8gJiBCVFVT
Ql9BVEgzMDEyKSB7DQo+ID4gKwkJc3RydWN0IHVzYl9kZXZpY2UgKnVkZXYgPSBpbnRlcmZhY2Vf
dG9fdXNiZGV2KGludGYpOw0KPiA+ICsJCWlmKGxlMTZfdG9fY3B1KHVkZXYtPmRlc2NyaXB0b3Iu
YmNkRGV2aWNlKSA8PSAweDAwMDEpDQo+ID4gKwkJCXJldHVybiAtRU5PREVWOw0KPiA+ICsJfQ0K
PiANCj4gQ29kaW5nIHN0eWxlIGZpeCBhcyB3ZWxsIHBsZWFzZS4gSSB3b3VsZCBzYXkgc29tZXRo
aW5nIHNpbWlsYXIgaW4gc3R5bGUNCj4gdG8gd2hhdCBJIGhhdmUgZG9uZSBmb3IgdGhlIG9sZGVy
IENTUiBjaGlwcy4gU2VlIHdvcmthcm91bmQgYWJvdmUuDQo+IA0KPiBBbmQgb24gdGhhdCBub3Rl
LCB5b3UgY291bGQgdXNlIGRhdGEtPnVkZXYgdG8gZ2V0IHRoZSB1c2JfZGV2aWNlDQo+IHN0cnVj
dCA7KQ0KPiANCj4gUmVnYXJkcw0KPiANCj4gTWFyY2VsDQo+IA0KDQo=

Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Gustavo F. Padovan]

Hi Steven,

Please stop messy top postings like this one. It's not allowed on this mailing
list. Thanks.

* Li, Steven <yongli@qca.qualcomm.com> [2011-06-29 03:51:03 +0000]:

> Hi Marcel:
> 
> > please fix the coding style. It is if[space](.
> Okay, I see.
> 
> > I would say something similar in style
> > to what I have done for the older CSR chips. See workaround above.
> > And on that note, you could use data->udev to get the usb_device
> > struct ;)
> As to this point,  since now we are not using the btusb to download the patch and radio table,
>  I think we do not need to alloc the data struct and use data->udev before the workaround.  
> So I'll still keep it was.  How do you think it ?

No, there is no extra allocation. data->udev is already there. Just use it as
Marcel said.

	Gustavo

RE: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Li, Steven]

Hi Padovan:

> -----Original Message-----
> From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf Of
> Gustavo F. Padovan
> Sent: Wednesday, June 29, 2011 12:32 PM
> To: Li, Steven
> Cc: Marcel Holtmann; linux-bluetooth@vger.kernel.org
> Subject: Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after
> downloading the patch and radio table
> 
> Hi Steven,
> 
> Please stop messy top postings like this one. It's not allowed on this mailing
> list. Thanks.
> 
> * Li, Steven <yongli@qca.qualcomm.com> [2011-06-29 03:51:03 +0000]:
> 
> > Hi Marcel:
> >
> > > please fix the coding style. It is if[space](.
> > Okay, I see.
> >
> > > I would say something similar in style
> > > to what I have done for the older CSR chips. See workaround above.
> > > And on that note, you could use data->udev to get the usb_device
> > > struct ;)
> > As to this point,  since now we are not using the btusb to download the
> patch and radio table,
> >  I think we do not need to alloc the data struct and use data->udev before
> the workaround.
> > So I'll still keep it was.  How do you think it ?
> 
> No, there is no extra allocation. data->udev is already there. Just use it as
> Marcel said.

There is somehow different with  the older CSR chips.
We need to return -NODEV directly if the bcd version of the 3012 chip is lower or equal to 0x0001,
And I think in such "return -NODEV" case, we totally do not need to alloc the btusb_data.

Thanks,
Best Regards,
Steven,

Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Gustavo F. Padovan]

* Li, Steven <yongli@qca.qualcomm.com> [2011-06-29 06:14:34 +0000]:

> 
> Hi Padovan:
> 
> > -----Original Message-----
> > From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf Of
> > Gustavo F. Padovan
> > Sent: Wednesday, June 29, 2011 12:32 PM
> > To: Li, Steven
> > Cc: Marcel Holtmann; linux-bluetooth@vger.kernel.org
> > Subject: Re: [PATCH] Bluetooth: Ath3k keeps same PID/VID after
> > downloading the patch and radio table
> > 
> > Hi Steven,
> > 
> > Please stop messy top postings like this one. It's not allowed on this mailing
> > list. Thanks.
> > 
> > * Li, Steven <yongli@qca.qualcomm.com> [2011-06-29 03:51:03 +0000]:
> > 
> > > Hi Marcel:
> > >
> > > > please fix the coding style. It is if[space](.
> > > Okay, I see.
> > >
> > > > I would say something similar in style
> > > > to what I have done for the older CSR chips. See workaround above.
> > > > And on that note, you could use data->udev to get the usb_device
> > > > struct ;)
> > > As to this point,  since now we are not using the btusb to download the
> > patch and radio table,
> > >  I think we do not need to alloc the data struct and use data->udev before
> > the workaround.
> > > So I'll still keep it was.  How do you think it ?
> > 
> > No, there is no extra allocation. data->udev is already there. Just use it as
> > Marcel said.
> 
> There is somehow different with  the older CSR chips.
> We need to return -NODEV directly if the bcd version of the 3012 chip is lower or equal to 0x0001,
> And I think in such "return -NODEV" case, we totally do not need to alloc the btusb_data.

Ah yes, you right, I misread the patch.

	Gustavo

RE: [PATCH] Bluetooth: Ath3k keeps same PID/VID after downloading the patch and radio table

[Li, Steven]

Hi Padovan :

> > > > > I would say something similar in style
> > > > > to what I have done for the older CSR chips. See workaround above=
.
> > > > > And on that note, you could use data->udev to get the usb_device
> > > > > struct ;)
> > > > As to this point,  since now we are not using the btusb to download=
 the
> > > patch and radio table,
> > > >  I think we do not need to alloc the data struct and use data->udev
> before
> > > the workaround.
> > > > So I'll still keep it was.  How do you think it ?
> > >
> > > No, there is no extra allocation. data->udev is already there. Just u=
se it as
> > > Marcel said.
> >
> > There is somehow different with  the older CSR chips.
> > We need to return -NODEV directly if the bcd version of the 3012 chip i=
s
> lower or equal to 0x0001,
> > And I think in such "return -NODEV" case, we totally do not need to all=
oc
> the btusb_data.
>=20
> Ah yes, you right, I misread the patch.
>=20

I have re-sent the patch to the mail list.
Btw, I changed the subject of the PATCH to make it be less than 60 characte=
rs.

Thanks, Padovan,
Steven,