Marcel, I was just poked about this thread:
http://www.spinics.net/lists/linux-bluetooth/msg06087.html
The hack is required because our BT hardware does not accept HCI commands
when the device is plugged in. If I understood your position you did not
want to accept the patch because our BT USB devices are violating the
specification by not acceping HCI commands and yet claiming to be BT
devices, is that right?
This position seems perfectly reasonable, and if it is violating the
specification this needs to be fixed in hardware for future devices. But
what is done is done, an dwe need to support existing customers with
current hardware, can you provide some recommendation as to an alternative
approach to resolve this upstream?
Without a patch like the one suggested Atheros' Bluetooth USB devices are
essentially not functional at all. I am in hopes we can come to some agreement
how to deal with a hardware quirk for now while we nag at our hardware team
to consider changing the way our devices work.
Someone from the Atheros BT team: can you send me the same patch to be
applied into compat-wireless under the linux-next-pending/ directory ?
That is, send me a patch which will apply onto compat-wireless.
This way we can actually get our hardware functional to customers while
we try to look for a better alternative directly upstream. You will
also need to document this issue on the wiki. I recommend you document
this here:
http://wireless.kernel.org/en/users/Drivers/ath3k
That is, create a new wiki page there for the driver and the things
needed for it. Once I get the patch into compat-wireless we can
refer users/customers to the compat-wireless stable releases with
the linux-next-pending/ patch you give to me applied.
Someone from the Atheros BT team: does the patch currently handle
suspend/resume?
Luis
On Fri, Sep 24, 2010 at 4:07 PM, Luis R. Rodriguez
<[email protected]> wrote:
> Marcel, I was just poked about this thread:
>
> http://www.spinics.net/lists/linux-bluetooth/msg06087.html
>
> The hack is required because our BT hardware does not accept HCI commands
> when the device is plugged in. If I understood your position you did not
> want to accept the patch because our BT USB devices are violating the
> specification by not acceping HCI commands and yet claiming to be BT
> devices, is that right?
>
> This position seems perfectly reasonable, and if it is violating the
> specification this needs to be fixed in hardware for future devices. But
> what is done is done, and we need to support existing customers with
> current hardware, can you provide some recommendation as to an alternative
> approach to resolve this upstream?
Marcel some attention to this would be greatly appreciated.
> Without a patch like the one suggested Atheros' Bluetooth USB devices are
> essentially not functional at all. I am in hopes we can come to some agreement
> how to deal with a hardware quirk for now while we nag at our hardware team
> to consider changing the way our devices work.
I have gotten clarifications from Ken Steck that this issue is only
present on AR3011 chips used in the SFLASH configuration. AR3012 will
not have this issue.
> Someone from the Atheros BT team: can you send me the same patch to be
> applied into compat-wireless under the linux-next-pending/ directory ?
> That is, send me a patch which will apply onto compat-wireless.
> This way we can actually get our hardware functional to customers while
> we try to look for a better alternative directly upstream. You will
> also need to document this issue on the wiki. I recommend you document
> this here:
>
> http://wireless.kernel.org/en/users/Drivers/ath3k
>
> That is, create a new wiki page there for the driver and the things
> needed for it. Once I get the patch into compat-wireless we can
> refer users/customers to the compat-wireless stable releases with
> the linux-next-pending/ patch you give to me applied.
I saw no takers on this.. so I just created the page myself.
> Someone from the Atheros BT team: does the patch currently handle
> suspend/resume?
Shanmugamkamatchi has noted to me he will be sending me this patch
soon and it also supports suspend/resume properly, however, I would
like to resolve this upstream.
Marcel, please let us know what path you recommend we take for this.
Luis
SGkgTWFyY2VsLCBCYWxhLA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogbGludXgtYmx1ZXRvb3RoLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LWJs
dWV0b290aC0NCj4gb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgTWFyY2VsIEhv
bHRtYW5uDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDA3LCAyMDEwIDk6NDIgQU0NCj4gVG86
IFNoYW5tdWdhbWthbWF0Y2hpIEJhbGFzaGFubXVnYW0NCj4gQ2M6IFNoYW5tdWdhbWthbWF0Y2hp
IEJhbGFzaGFubXVnYW07IEx1aXMgUm9kcmlndWV6OyBKb2hhbm5lcyBCZXJnOw0KPiBsaW51eC1i
bHVldG9vdGg7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LQ0KPiB3aXJlbGVz
c0B2Z2VyLmtlcm5lbC5vcmc7IERlZXBhayBEaGFtZGhlcmU7IFNyZWUgRHVyYmhhDQo+IFN1Ympl
Y3Q6IFJlOiBSRkM6IGJ0dXNiIGZpcm13YXJlIGxvYWQgaGVscA0KPiANCj4gSGkgQmFsYSwNCj4g
DQo+ID4gPj4gVGhhbmtzIEpvaGFubmVzLiAgVGhpcyB3b3VsZCBiZSBiZXR0ZXIgb3B0aW9uIHRv
IGNoYW5nZSBQSUQgaW4NCj4gZmlybXdhcmUNCj4gPiA+PiBhcyBibGFja2xpc3RpbmcgMzAwMiBt
aWdodCBjcmVhdGUgcHJvYmxlbXMgZm9yIDMwMTEgY2hpcHNldHMuDQo+ID4gPj4gV2lsbCB0cnkg
YW5kIGxldCB5b3UgcGVvcGxlIGtub3cuDQo+ID4gPiBUaGUgbWlzYmVoYXZpbmcgMzAwMiBuZWVk
cyB0byBiZSBibGFja2xpc3RlZCBpbiBidHVzYi5jIGFueXdheS4NCj4gSG93ZXZlcg0KPiA+ID4g
YWZ0ZXIgbG9hZGluZyB0aGUgZmlybXdhcmUgdG8gMzAwMiBkZXZpY2UsIGl0IHNob3VsZCBjaGFu
Z2UgaXRzIFBJRA0KPiB0bw0KPiA+ID4gc29tZXRoaW5nIGVsc2UuDQo+ID4gPg0KPiA+ID4gSSBh
bSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dCBpZiB0aGlzIGlzIG9uZSBzdGFnZSBmaXJtd2Fy
ZQ0KPiBsb2FkaW5nIG9yDQo+ID4gPiBhIHR3byBzdGFnZSBmaXJtd2FyZSBsb2FkaW5nLiBUaGlz
IGlzIGFsbCBwcmV0dHkgdW5jbGVhciBhbmQgbm9ib2R5DQo+IGhhcw0KPiA+ID4gYW5zd2VyZWQg
dGhpcyBjbGVhcmx5IHNvIGZhci4NCj4gPg0KPiA+IGVlcHJvbSBiYXNlZCAzMDExIGNoaXBzIGNv
bWVzIHVwIHdpdGggUElEIDMwMDAgZ2l2aW5nIGNvbnRyb2wgdG8gREZVDQo+ID4gZHJpdmVyIFth
dGgza10uICBhdGgzayBkb3dubG9hZHMgdGhlDQo+ID4gZmlybXdhcmUgY2hhbmdpbmcgUElEIHRv
IDMwMDIuICBOb3cgYnR1c2IgZ2V0cyBjb250cm9sLg0KPiA+DQo+ID4gSW4gc2ZsYXNoIGJhc2Vk
IGRldmljZXMgdG8gcmVkdWNlIHdpbmRvd3Mgc3VzcGVuZC9yZXN1bWUgdGltZSB3ZSBoYWQNCj4g
YQ0KPiA+IHNtYWxsIGZpcm13YXJlIGluIGZsYXNoIHdoaWNoDQo+ID4gZW5hYmxlcyB0aGUgZGV2
aWNlIHRvIGdldCBkZXRlY3RlZCBhcyBHZW5lcmljIEJsdWV0b290aCBVU0IgZGV2aWNlDQo+IHdp
dGgNCj4gPiBQSUQgMzAwMi4gIFNvIGNvbnRyb2wgcmVhY2hlcyBidHVzYiB3aGVuIGRldmljZSBp
cyBwbHVnZ2VkIGluLA0KPiBsZWF2aW5nDQo+ID4gbm8gb3B0aW9uIGZvciB1cyB0byBsb2FkIHRo
ZSBhY3R1YWwgZmlybXdhcmUuDQo+ID4NCj4gPiBTb2x1dGlvbiB3b3VsZCBiZSB0byBibGFja2xp
c3QgMzAwMiBpbiBidHVzYiwgZW5hYmxlIGF0aDNrIHRvIGdldA0KPiA+IGNvbnRyb2wgZm9yIGJv
dGggdGhlIGRldmljZXMsIGRvd25sb2FkIHRoZSBmaXJtd2FyZSBhbmQgY2hhbmdlIFBJRCB0bw0K
PiA+IDMwMDMgc28gdGhhdCBjb250cm9sIHdpdGggY29tZSB0byBidHVzYi4NCj4gDQo+IHNvIGhl
cmUgaXMgdGhlIHRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgZG9uZS4NCj4gDQo+IGEpIEdldCBhIGZp
cm13YXJlIGZvciBQSUQgMzAwMCBkZXZpY2VzIHRoYXQgY2hhbmdlIHRoZSBmaXJtd2FyZSB0byBz
b21lDQo+IG90aGVyIFBJRC4gU2luY2UgMzAwMyBpcyBhbHJlYWR5IGluIHVzZSBhcyB3ZWxsLCB1
c2luZyAzMDA0IG9yIGxhdGVyIGlzDQo+IGJldHRlciBhcHByb2FjaC4NCj4gDQo+IGIpIEJsYWNr
bGlzdCBQSUQgMzAwMiBpbiBidHVzYi5jLg0KPiANCj4gYykgSGFuZGxlIHNwZWNpYWwgZmlybXdh
cmUgbG9hZGluZyBjYXNlIGZvciBQSUQgMzAwMiBzZmxhc2ggZGV2aWNlcy4gSWYNCj4gZmlybXdh
cmUgaXMgbG9hZGVkIGNoYW5nZWQgdG8gMzAwNSBvciBvdGhlci4NCj4gDQo+IEFuZCBhcyBhIGdl
bmVyYWwgbm90ZSwgSSBwcmVmZXIgdGhhdCB0aGUgUElEIGFmdGVyIGxvYWRpbmcgZmlybXdhcmUg
aXMNCj4gZGlmZmVyZW50IGlmIHlvdSBkb24ndCBoYXBwZW4gdG8gYWN0dWFsbHkgbG9hZCB0aGUg
c2FtZSBmaXJtd2FyZS4NCj4gDQo+IFNvIHBsZWFzZSBzb3J0IG91dCB5b3VyIFVTQiBQSUQgYXNz
aWdubWVudCBmb3IgQmx1ZXRvb3RoIGluIGdlbmVyYWwuDQo+IFRoaXMgc2VlbXMgdG8gYmUgYSBt
ZXNzIHRoYXQgaXMgbm90IHRob3VnaHQgdGhyb3VnaCBwcm9wZXJseS4NCj4gDQo+IFJlZ2FyZHMN
Cj4gDQo+IE1hcmNlbA0KPiANCg0KWWVzLCBpdCBpcyBhIGdvb2QgaWRlYSB0byBsZXQgdGhlIGRv
d25sb2FkYWJsZSBmaXJtd2FyZSBzZXQgYSBuZXcgUElELCBhbG9uZyB3aXRoIHRoZSBibGFja2xp
c3Qgb24gdGhlIDMwMDIgUElEIGZvciB0aGUgZmlyc3QgZ28gcm91bmQuICBJIGVtcGhhc2l6ZSwg
aXQgaXMgdGhlIGRvd25sb2FkZWQgZmlybXdhcmUgdGhhdCB3aWxsIGJlIHJlcXVpcmVkIHRvIGRv
IHRoZSBQSUQgc3dpenpsaW5nLCBub3QgdGhlIHNmbGFzaCBmaXJtd2FyZS4gIEFuZCBJIGFncmVl
IHdlIHNob3VsZCBoYXZlIGEgbWFwIG9mIHRoZSBQSURzIGluIHVzZSBhbmQgd2hhdCB0aGV5IGFy
ZSB1c2VkIGZvciwgb25jZSB3ZSBnZXQgdGhyb3VnaCB0aGlzIGltbWVkaWF0ZSBmaXhpbmcgcGhh
c2UuDQoNClRoYW5rcywNCg0KCUsrKw0KDQoNCg0K
Hi Johannes,
> > I am still trying to figure out if this is one stage firmware loading or
> > a two stage firmware loading. This is all pretty unclear and nobody has
> > answered this clearly so far.
>
> afaict, it's just one stage -- either it has sflash and you load ath3k
> firmware over it (the problematic 3002-before-loading case), or it
> doesn't have any firmware (and comes up with 3000) and you load the same
> ath3k firmware over it with a different mechanism, which currently
> announces itself as 3002 but can be changed.
sounds a lot better than what I understood initially. So essentially the
PID assigned for their different devices got screwed up. So that needs
to be fixed now.
Regards
Marcel
Hi Bala,
> >>>> Thanks Johannes. This would be better option to change PID in firmware
> >>>> as blacklisting 3002 might create problems for 3011 chipsets.
> >>>> Will try and let you people know.
> >>> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
> >>> after loading the firmware to 3002 device, it should change its PID to
> >>> something else.
> >>>
> >>> I am still trying to figure out if this is one stage firmware loading or
> >>> a two stage firmware loading. This is all pretty unclear and nobody has
> >>> answered this clearly so far.
> >> eeprom based 3011 chips comes up with PID 3000 giving control to DFU
> >> driver [ath3k]. ath3k downloads the
> >> firmware changing PID to 3002. Now btusb gets control.
> >>
> >> In sflash based devices to reduce windows suspend/resume time we had a
> >> small firmware in flash which
> >> enables the device to get detected as Generic Bluetooth USB device with
> >> PID 3002. So control reaches btusb when device is plugged in, leaving
> >> no option for us to load the actual firmware.
> >>
> >> Solution would be to blacklist 3002 in btusb, enable ath3k to get
> >> control for both the devices, download the firmware and change PID to
> >> 3003 so that control with come to btusb.
> > so here is the thing that needs to be done.
> >
> > a) Get a firmware for PID 3000 devices that change the firmware to some
> > other PID. Since 3003 is already in use as well, using 3004 or later is
> > better approach.
> >
> > b) Blacklist PID 3002 in btusb.c.
> >
> > c) Handle special firmware loading case for PID 3002 sflash devices. If
> > firmware is loaded changed to 3005 or other.
> >
> > And as a general note, I prefer that the PID after loading firmware is
> > different if you don't happen to actually load the same firmware.
> >
> > So please sort out your USB PID assignment for Bluetooth in general.
> > This seems to be a mess that is not thought through properly.
> >
> >
> Thanks for your suggestion Marcel.
> Can't we have same PID[3004 or later] for both the devices after loading
> the firmware by ath3k?
> We need two different firmware if we plan to have two different PIDs for
> these two bluetooth devices.
if it loads the same firmware into the device, then it is just fine to
share a PID. If it loads different firmware, then I would propose
different PIDs.
So yes, you can use the PID since you wanna keep the firmware the same.
That is perfectly fine and reasonable.
Regards
Marcel
On Thu, 2010-10-07 at 17:24 +0200, Marcel Holtmann wrote:
> I am still trying to figure out if this is one stage firmware loading or
> a two stage firmware loading. This is all pretty unclear and nobody has
> answered this clearly so far.
afaict, it's just one stage -- either it has sflash and you load ath3k
firmware over it (the problematic 3002-before-loading case), or it
doesn't have any firmware (and comes up with 3000) and you load the same
ath3k firmware over it with a different mechanism, which currently
announces itself as 3002 but can be changed.
johannes
On Thu, 2010-10-07 at 22:02 +0530, Bala Shanmugam wrote:
> AR3011 when plugged-in uses PID 3000 and control goes to DFU driver [ath3k].
> ath3k downloads the firmware to the device changing its PID to 3002.
> Now btusb gets the control and attaches the device to bluetooth core.
>
> So blacklisting 3002 in btusb will create issues for AR3011 chipsets.
> In firmware if we change the PID from 3002 to 3003 as you suggested and
> blacklist 3002 in btusb we can make both devices work.
Yeah, that still seems like the best approach, or maybe 3004 instead of
3003 if 3003 is already in use by a different chip, or whatever.
johannes
On 10/7/2010 10:12 PM, Marcel Holtmann wrote:
> Hi Bala,
>
>>>> Thanks Johannes. This would be better option to change PID in firmware
>>>> as blacklisting 3002 might create problems for 3011 chipsets.
>>>> Will try and let you people know.
>>> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
>>> after loading the firmware to 3002 device, it should change its PID to
>>> something else.
>>>
>>> I am still trying to figure out if this is one stage firmware loading or
>>> a two stage firmware loading. This is all pretty unclear and nobody has
>>> answered this clearly so far.
>> eeprom based 3011 chips comes up with PID 3000 giving control to DFU
>> driver [ath3k]. ath3k downloads the
>> firmware changing PID to 3002. Now btusb gets control.
>>
>> In sflash based devices to reduce windows suspend/resume time we had a
>> small firmware in flash which
>> enables the device to get detected as Generic Bluetooth USB device with
>> PID 3002. So control reaches btusb when device is plugged in, leaving
>> no option for us to load the actual firmware.
>>
>> Solution would be to blacklist 3002 in btusb, enable ath3k to get
>> control for both the devices, download the firmware and change PID to
>> 3003 so that control with come to btusb.
> so here is the thing that needs to be done.
>
> a) Get a firmware for PID 3000 devices that change the firmware to some
> other PID. Since 3003 is already in use as well, using 3004 or later is
> better approach.
>
> b) Blacklist PID 3002 in btusb.c.
>
> c) Handle special firmware loading case for PID 3002 sflash devices. If
> firmware is loaded changed to 3005 or other.
>
> And as a general note, I prefer that the PID after loading firmware is
> different if you don't happen to actually load the same firmware.
>
> So please sort out your USB PID assignment for Bluetooth in general.
> This seems to be a mess that is not thought through properly.
>
> Regards
>
> Marcel
>
>
Thanks for your suggestion Marcel.
Can't we have same PID[3004 or later] for both the devices after loading
the firmware by ath3k?
We need two different firmware if we plan to have two different PIDs for
these two bluetooth devices.
Regards,
Bala.
Hi Bala,
> >> Thanks Johannes. This would be better option to change PID in firmware
> >> as blacklisting 3002 might create problems for 3011 chipsets.
> >> Will try and let you people know.
> > The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
> > after loading the firmware to 3002 device, it should change its PID to
> > something else.
> >
> > I am still trying to figure out if this is one stage firmware loading or
> > a two stage firmware loading. This is all pretty unclear and nobody has
> > answered this clearly so far.
>
> eeprom based 3011 chips comes up with PID 3000 giving control to DFU
> driver [ath3k]. ath3k downloads the
> firmware changing PID to 3002. Now btusb gets control.
>
> In sflash based devices to reduce windows suspend/resume time we had a
> small firmware in flash which
> enables the device to get detected as Generic Bluetooth USB device with
> PID 3002. So control reaches btusb when device is plugged in, leaving
> no option for us to load the actual firmware.
>
> Solution would be to blacklist 3002 in btusb, enable ath3k to get
> control for both the devices, download the firmware and change PID to
> 3003 so that control with come to btusb.
so here is the thing that needs to be done.
a) Get a firmware for PID 3000 devices that change the firmware to some
other PID. Since 3003 is already in use as well, using 3004 or later is
better approach.
b) Blacklist PID 3002 in btusb.c.
c) Handle special firmware loading case for PID 3002 sflash devices. If
firmware is loaded changed to 3005 or other.
And as a general note, I prefer that the PID after loading firmware is
different if you don't happen to actually load the same firmware.
So please sort out your USB PID assignment for Bluetooth in general.
This seems to be a mess that is not thought through properly.
Regards
Marcel
On 10/7/2010 8:54 PM, Marcel Holtmann wrote:
> Hi Bala,
>
>> Thanks Johannes. This would be better option to change PID in firmware
>> as blacklisting 3002 might create problems for 3011 chipsets.
>> Will try and let you people know.
> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
> after loading the firmware to 3002 device, it should change its PID to
> something else.
>
> I am still trying to figure out if this is one stage firmware loading or
> a two stage firmware loading. This is all pretty unclear and nobody has
> answered this clearly so far.
>
> Regards
>
> Marcel
>
>
Marcel,
eeprom based 3011 chips comes up with PID 3000 giving control to DFU
driver [ath3k]. ath3k downloads the
firmware changing PID to 3002. Now btusb gets control.
In sflash based devices to reduce windows suspend/resume time we had a
small firmware in flash which
enables the device to get detected as Generic Bluetooth USB device with
PID 3002. So control reaches btusb when device is plugged in, leaving
no option for us to load the actual firmware.
Solution would be to blacklist 3002 in btusb, enable ath3k to get
control for both the devices, download the firmware and change PID to
3003 so that control with come to btusb.
Thanks for your time.
Regards,
Bala.
On 10/7/2010 8:54 PM, Marcel Holtmann wrote:
> Hi Bala,
>
>> Thanks Johannes. This would be better option to change PID in firmware
>> as blacklisting 3002 might create problems for 3011 chipsets.
>> Will try and let you people know.
> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
> after loading the firmware to 3002 device, it should change its PID to
> something else.
>
> I am still trying to figure out if this is one stage firmware loading or
> a two stage firmware loading. This is all pretty unclear and nobody has
> answered this clearly so far.
>
> Regards
>
> Marcel
>
>
h
On 10/7/2010 8:45 PM, Johannes Berg wrote:
>> Thanks Johannes. This would be better option to change PID in firmware
>> as blacklisting 3002 might create problems for 3011 chipsets.
> What would be the problem with 3011? Does it also use the 3002 ID, but
> not use firmware upload???
>
> johannes
>
AR3011 when plugged-in uses PID 3000 and control goes to DFU driver [ath3k].
ath3k downloads the firmware to the device changing its PID to 3002.
Now btusb gets the control and attaches the device to bluetooth core.
So blacklisting 3002 in btusb will create issues for AR3011 chipsets.
In firmware if we change the PID from 3002 to 3003 as you suggested and
blacklist 3002 in btusb
we can make both devices work.
Regards,
Bala.
Hi Bala,
> Thanks Johannes. This would be better option to change PID in firmware
> as blacklisting 3002 might create problems for 3011 chipsets.
> Will try and let you people know.
The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
after loading the firmware to 3002 device, it should change its PID to
something else.
I am still trying to figure out if this is one stage firmware loading or
a two stage firmware loading. This is all pretty unclear and nobody has
answered this clearly so far.
Regards
Marcel
> Thanks Johannes. This would be better option to change PID in firmware
> as blacklisting 3002 might create problems for 3011 chipsets.
What would be the problem with 3011? Does it also use the 3002 ID, but
not use firmware upload???
johannes
________________________________________
From: [email protected] [[email protected]] On Behalf Of Luis R. Rodriguez [[email protected]]
Sent: Thursday, October 07, 2010 12:03 AM
To: Johannes Berg
Cc: Luis Rodriguez; Marcel Holtmann; linux-bluetooth; [email protected]; [email protected]; Deepak Dhamdhere; Sree Durbha
Subject: Re: RFC: btusb firmware load help
On Wed, Oct 06, 2010 at 11:28:17AM -0700, Johannes Berg wrote:
> On Wed, 2010-10-06 at 11:26 -0700, Luis R. Rodriguez wrote:
>
> > > Good idea, I forgot about possible firmware changes :) Lets see if our
> > > team can do that. Thanks for all the feedback.
> >
> > Deepak a proof of concept test can involve simply hex-editing the
> > ath3k-1.fw and replacing 0x3002 to 0x3003, then the above patch might
> > work.
>
> $ hd ath3k-1.fw
> ...
> 00000670 00 00 00 00 00 00 00 00 00 00 00 00 f3 0c 02 30 |...............0|
> 00000680 12 01 10 01 e0 01 01 40 f3 0c 02 30 01 00 00 00 |[email protected]....|
> ...
>
> that looks a lot like the IDs right there, in little endian :-)
>Furthermore another idea by johannes is that if we cannot fix this
>in firmware by changing the exposed device ID, we could just check
>in btusb for some USB component that would come alive once the firmware
>does get loaded, like endpoints, or speed, or whatever. But that would
>be last resort.
> Luis
>--
>To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks Johannes. This would be better option to change PID in firmware
as blacklisting 3002 might create problems for 3011 chipsets.
Will try and let you people know.
Regards,
Bala.
On Wed, Oct 06, 2010 at 11:28:17AM -0700, Johannes Berg wrote:
> On Wed, 2010-10-06 at 11:26 -0700, Luis R. Rodriguez wrote:
>
> > > Good idea, I forgot about possible firmware changes :) Lets see if our
> > > team can do that. Thanks for all the feedback.
> >
> > Deepak a proof of concept test can involve simply hex-editing the
> > ath3k-1.fw and replacing 0x3002 to 0x3003, then the above patch might
> > work.
>
> $ hd ath3k-1.fw
> ...
> 00000670 00 00 00 00 00 00 00 00 00 00 00 00 f3 0c 02 30 |...............0|
> 00000680 12 01 10 01 e0 01 01 40 f3 0c 02 30 01 00 00 00 |[email protected]....|
> ...
>
> that looks a lot like the IDs right there, in little endian :-)
Furthermore another idea by johannes is that if we cannot fix this
in firmware by changing the exposed device ID, we could just check
in btusb for some USB component that would come alive once the firmware
does get loaded, like endpoints, or speed, or whatever. But that would
be last resort.
Luis
On Wed, 2010-10-06 at 11:26 -0700, Luis R. Rodriguez wrote:
> > Good idea, I forgot about possible firmware changes :) Lets see if our
> > team can do that. Thanks for all the feedback.
>
> Deepak a proof of concept test can involve simply hex-editing the
> ath3k-1.fw and replacing 0x3002 to 0x3003, then the above patch might
> work.
$ hd ath3k-1.fw
...
00000670 00 00 00 00 00 00 00 00 00 00 00 00 f3 0c 02 30 |...............0|
00000680 12 01 10 01 e0 01 01 40 f3 0c 02 30 01 00 00 00 |[email protected]....|
...
that looks a lot like the IDs right there, in little endian :-)
johannes
On Wed, Oct 6, 2010 at 10:54 AM, Johannes Berg
<[email protected]> wrote:
> On Wed, 2010-10-06 at 10:39 -0700, Luis R. Rodriguez wrote:
>
>
>> > With sflash based AR3011 hardware, when we connect the device to USB
>> > port it gets detected as a Bluetooth device because of firmware in
>> > Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub
>> > system driver (btusb.ko) directly in the host instead of ath3k
>> > DFU driver. Therefore, there is no firmware downloaded in to the
>> > RAM to bring up Bluetooth at this point. This is the problem
>> > we're trying to "fix".
>
> So the easiest fix for this would be to
> a) ignore 0x0cf3,0x3002 in btusb
> b) add it to ath3k firmware loading
> c) change the ath3k firmware to load with 0x0cf3,0x3003 (or whatever
> else you want, as long as it's not 0x3000 and not 0x3002)
>
> Then the ignore in btusb won't affect ath3k after that new firmware was
> loaded.
Good idea, I forgot about possible firmware changes :) Lets see if our
team can do that. Thanks for all the feedback.
Luis
On Wed, Oct 6, 2010 at 11:22 AM, Luis R. Rodriguez
<[email protected]> wrote:
> On Wed, Oct 6, 2010 at 10:54 AM, Johannes Berg
> <[email protected]> wrote:
>> On Wed, 2010-10-06 at 10:39 -0700, Luis R. Rodriguez wrote:
>>
>>
>>> > With sflash based AR3011 hardware, when we connect the device to USB
>>> > port it gets detected as a Bluetooth device because of firmware in
>>> > Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub
>>> > system driver (btusb.ko) directly in the host instead of ath3k
>>> > DFU driver. Therefore, there is no firmware downloaded in to the
>>> > RAM to bring up Bluetooth at this point. This is the problem
>>> > we're trying to "fix".
>>
>> So the easiest fix for this would be to
>> a) ignore 0x0cf3,0x3002 in btusb
>> b) add it to ath3k firmware loading
>> c) change the ath3k firmware to load with 0x0cf3,0x3003 (or whatever
>> else you want, as long as it's not 0x3000 and not 0x3002)
>>
>> Then the ignore in btusb won't affect ath3k after that new firmware was
>> loaded.
>
> Good idea, I forgot about possible firmware changes :) Lets see if our
> team can do that. Thanks for all the feedback.
Deepak a proof of concept test can involve simply hex-editing the
ath3k-1.fw and replacing 0x3002 to 0x3003, then the above patch might
work.
Luis
On Wed, 6 Oct 2010, Luis R. Rodriguez wrote:
> I just got this description from Sady:
>
> -------------------------------------------------------------------------------------------------------------------
> With eeprom based AR3011 hardware, normally this device gets detected
> as a normal USB device with VID=0x0CF3, PID=0x3000.
> Ath3k DFU driver will download the firmware in to RAM.
> Due to firmware download in the RAM it is exposed as new device
> with VID=0x0CF3, PID=0x3002 to host Bluetooth sub system and btusb.ko
> driver probe routine gets called to bring up Bluetooth interface.
> This is the normal procedure we have done so far on Linux.
>
> With sflash based AR3011 hardware, when we connect the device to USB
> port it gets detected as a Bluetooth device because of firmware in
> Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub
> system driver (btusb.ko) directly in the host instead of ath3k
> DFU driver. Therefore, there is no firmware downloaded in to the
> RAM to bring up Bluetooth at this point. This is the problem
> we're trying to "fix".
> -------------------------------------------------------------------------------------------------------------------
>
> With the above patch we'd get ath3k to do the firmware uploading but
> I'm afraid that we'll go into a loop here unless we can figure out a
> way to get btusb to know the device is now ready.
Modify the firmware file so that after loading the firmware it gets for
example VID=0x0CF3, PID=0x3003.
Blacklist VID=0x0CF3, PID=0x3002 in btusb and add it to ath3k.
>From then on VID=0x0CF3, PID=0x3000 and PID=0x3002 mean "need firmware"
and PID=0x3003 is the operational state (like half of your PID=0x3002
usage is now)
c'ya
sven-haegar
--
Three may keep a secret, if two of them are dead.
- Ben F.
On Wed, 2010-10-06 at 10:39 -0700, Luis R. Rodriguez wrote:
> > With sflash based AR3011 hardware, when we connect the device to USB
> > port it gets detected as a Bluetooth device because of firmware in
> > Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub
> > system driver (btusb.ko) directly in the host instead of ath3k
> > DFU driver. Therefore, there is no firmware downloaded in to the
> > RAM to bring up Bluetooth at this point. This is the problem
> > we're trying to "fix".
So the easiest fix for this would be to
a) ignore 0x0cf3,0x3002 in btusb
b) add it to ath3k firmware loading
c) change the ath3k firmware to load with 0x0cf3,0x3003 (or whatever
else you want, as long as it's not 0x3000 and not 0x3002)
Then the ignore in btusb won't affect ath3k after that new firmware was
loaded.
johannes
On Wed, Oct 06, 2010 at 10:37:46AM -0700, Luis R. Rodriguez wrote:
> On Wed, Oct 6, 2010 at 9:38 AM, Luis R. Rodriguez
> <[email protected]> wrote:
> > 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 */
> > ?};
>
> I just got this description from Sady:
>
> -------------------------------------------------------------------------------------------------------------------
> With eeprom based AR3011 hardware, normally this device gets detected
> as a normal USB device with VID=0x0CF3, PID=0x3000.
> Ath3k DFU driver will download the firmware in to RAM.
> Due to firmware download in the RAM it is exposed as new device
> with VID=0x0CF3, PID=0x3002 to host Bluetooth sub system and btusb.ko
> driver probe routine gets called to bring up Bluetooth interface.
> This is the normal procedure we have done so far on Linux.
>
> With sflash based AR3011 hardware, when we connect the device to USB
> port it gets detected as a Bluetooth device because of firmware in
> Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub
> system driver (btusb.ko) directly in the host instead of ath3k
> DFU driver. Therefore, there is no firmware downloaded in to the
> RAM to bring up Bluetooth at this point. This is the problem
> we're trying to "fix".
> -------------------------------------------------------------------------------------------------------------------
>
> With the above patch we'd get ath3k to do the firmware uploading but
> I'm afraid that we'll go into a loop here unless we can figure out a
> way to get btusb to know the device is now ready.
Oh and we'd still need something like this instead:
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 128cae4..c90512d 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -35,6 +35,7 @@
static struct usb_device_id ath3k_table[] = {
/* Atheros AR3011 */
{ USB_DEVICE(0x0CF3, 0x3000) },
+ { USB_DEVICE(0x0CF3, 0x3002) },
{ } /* Terminating entry */
};
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 */
};
But yeah, not sure how to prevent a loop. I'm actually not sure
what would happen once we hit the ath3k driver on the sflash
based devices with this patch.
Luis
On Wed, Oct 6, 2010 at 9:38 AM, Luis R. Rodriguez
<[email protected]> wrote:
> 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 */
> };
I just got this description from Sady:
-------------------------------------------------------------------------------------------------------------------
With eeprom based AR3011 hardware, normally this device gets detected
as a normal USB device with VID=0x0CF3, PID=0x3000.
Ath3k DFU driver will download the firmware in to RAM.
Due to firmware download in the RAM it is exposed as new device
with VID=0x0CF3, PID=0x3002 to host Bluetooth sub system and btusb.ko
driver probe routine gets called to bring up Bluetooth interface.
This is the normal procedure we have done so far on Linux.
With sflash based AR3011 hardware, when we connect the device to USB
port it gets detected as a Bluetooth device because of firmware in
Flash (VID=0x0CF3, PID=0x3002). This triggers the Bluetooth sub
system driver (btusb.ko) directly in the host instead of ath3k
DFU driver. Therefore, there is no firmware downloaded in to the
RAM to bring up Bluetooth at this point. This is the problem
we're trying to "fix".
-------------------------------------------------------------------------------------------------------------------
With the above patch we'd get ath3k to do the firmware uploading but
I'm afraid that we'll go into a loop here unless we can figure out a
way to get btusb to know the device is now ready.
Luis
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 */
};
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.
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.
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.
Regards
Marcel
On Wed, Oct 6, 2010 at 12:19 AM, Marcel Holtmann
<[email protected]> wrote:
> Hi Luis,
>
>> > most likely via a separate firmware loading driver.
>>
>> Like the fwload patch ? Or something different?
>
> something clean of course and not this hacking around, but in general
> along that.
>
>> > Your ath3k driver is such a driver. Same as the bcm203x driver.
>>
>> Right -- so ath3k depends on some atheros USB device IDs, and its a
>> stupid driver that just loads firmware. The problem with this new
>> device is that it requires two phases. One to load some sort of
>> firmware onto it to get it to read as an ath3k device, and then ath3k
>> will load the right firmware to it. So the hardware device is already
>> claiming a btusb vendor:device ID, we can't change that I believe. Of
>> course for future devices we can, and we've addressed this and its
>> been fixed.
>
> So your current loading procedure is this:
>
> 1) btusb with hacked firmware loading
> 2) ath3k
> 3) btusb with HCI
Not sure of the 3rd part as I do not know what the ath3k firmware
does. I am not sure if by loading the ath3k firmware it then
redeclares itself as a btusb device. Also upon further review I just
noticed the fwload hack used ath3k-1.fw and not ath3k-2.fw. A patch
submitted ages ago to you added ath3k-2.fw upstream but that patch
never made it through upstream, so now I wonder if the fwload crap
thing should be using ath3k-2.fw as well. Anyway, I am also not sure
why after loading the firmware from btusb a second load using ath3k
driver would be needed.
> Who thought that this is a good idea in the first place?
Not sure, this was the way the hardware was designed, it just so
happens there seems to be no generic btusb module equivalent on
Windows or Mac OS X so they have full control over how this is handled
there and apparently in Windows and Mac OS X you can get away with
murder on crap code on drivers, so long as shit works. My
understanding is that the stuff implemented was just some workarounds
to get this to work on Linux. Due to our higher requirement on code
quality, and though process I recommend device drivers get written for
Linux first, perhaps a lesson will be learned here to try to do this
moving forward.
> And more important that I would accept this upstream? This is even worse than I
> thought it is.
Heh, I don't think anyone knew any better. Your suggestions of how to
handle this properly in a way that is agreeable to you is what we were
looking for.
> Please get this craziness fixed.
Without proper feedback the team was not sure what to do, the feedback
I read they got was what they were doing was was crazy but I also saw
no alternative method suggested. It took us a while (this thread) to
get alternatives suggested, but I appreciate them.
>> > They don't do anything than claiming that USB device, loading the firmware, and then let it reset.
>>
>> Right but if the SFLASH configurations hardware is already shipping
>> and without firmware is claiming to be a BT USB device which matches
>> the USB vendor:device ID of the btusb driver. Unfortunately it does
>> not accept HCI commands which as you indicates breaks some
>> specification. We can and have fixed this in future chipsets but this
>> one cannot be addressed. So what do we do?
>>
>> > And after the reset the btusb can claim the one where the firmware has
>> > been loaded and which behaves like a proper USB dongle.
>>
>> Right, that's what the fwload patch from our BT team does, no?
>
> Yes, but not inside the btusb driver. Stop hacking a generic driver with
> crazy firmware loading only because the USB Bluetooth class descriptors
> got screwed up in the first place.
Thanks for the pointers on this, I believe our team was not familiar
about these specification violations, they could have learned of the
violations through the old threads with you or through other means,
either way they have been addressed for future hardware it seems. So
while new hardware is fixed we still need to address this old hardware
situation. I'll be honest, our team actually gave up completely on
supporting the older hardware upstream on the Linux kernel as they
were under the impression there was no way to support the device in an
acceptable way by you. Our team should have nagged for alternatives
back then but it would have been easier if these would have come from
you instead of a simple NACK of the patch and indicating their
strategy to resolve this was loony.
>> > The part that I don't understand is that you have the ath3k driver doing
>> > it exactly how it should be done, why now started to make nasty hacks in
>> > the btusb driver.
>>
>> Yeah that seems to have been a shortcoming, its something you should
>> expect from us moving forward. I've been told AR3012 and future
>> Atheros chipsets will not have behave this way, and this issue is only
>> present for the AR3011 devices with SFLASH configuration.
>
> Most likely including the flashing into ath3k firmware loading driver
> and that being called bound twice might be a good idea.
Wouldn't ath3k have to claim the generic btusb device IDs for this to work?
> However we are not doing the firmware loading in btusb. Then a patch to blacklist this
> broken device. And then ensure that the firmware changes the USB PIDs
> after success.
>
> And if I understand you correct, then it does this anyway right now
> already. Otherwise the ath3k driver would not bind to it.
Right, I'm under the impression btusb will load, upload the ath3k-1.fw
to the device, then it re-enumerates itself to match the ath3k USB
vendor:device ID, then ath3k will once again load ath3k-1.fw. Not sure
what happens after that as that is all the code I see and am familiar
with. I'll remind you I am not a Bluetooth developer but an 802.11
developer dragged into this as no traction was being made and we need
to start supporting customers on Linux with this, so please bare with
me if I'm off on the BT stuff.
> 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?
Luis
Hi Luis,
> > most likely via a separate firmware loading driver.
>
> Like the fwload patch ? Or something different?
something clean of course and not this hacking around, but in general
along that.
> > Your ath3k driver is such a driver. Same as the bcm203x driver.
>
> Right -- so ath3k depends on some atheros USB device IDs, and its a
> stupid driver that just loads firmware. The problem with this new
> device is that it requires two phases. One to load some sort of
> firmware onto it to get it to read as an ath3k device, and then ath3k
> will load the right firmware to it. So the hardware device is already
> claiming a btusb vendor:device ID, we can't change that I believe. Of
> course for future devices we can, and we've addressed this and its
> been fixed.
So your current loading procedure is this:
1) btusb with hacked firmware loading
2) ath3k
3) btusb with HCI
Who thought that this is a good idea in the first place? And more
important that I would accept this upstream? This is even worse than I
thought it is.
Please get this craziness fixed.
> > They don't do anything than claiming that USB device, loading the firmware, and then let it reset.
>
> Right but if the SFLASH configurations hardware is already shipping
> and without firmware is claiming to be a BT USB device which matches
> the USB vendor:device ID of the btusb driver. Unfortunately it does
> not accept HCI commands which as you indicates breaks some
> specification. We can and have fixed this in future chipsets but this
> one cannot be addressed. So what do we do?
>
> > And after the reset the btusb can claim the one where the firmware has
> > been loaded and which behaves like a proper USB dongle.
>
> Right, that's what the fwload patch from our BT team does, no?
Yes, but not inside the btusb driver. Stop hacking a generic driver with
crazy firmware loading only because the USB Bluetooth class descriptors
got screwed up in the first place.
> > The part that I don't understand is that you have the ath3k driver doing
> > it exactly how it should be done, why now started to make nasty hacks in
> > the btusb driver.
>
> Yeah that seems to have been a shortcoming, its something you should
> expect from us moving forward. I've been told AR3012 and future
> Atheros chipsets will not have behave this way, and this issue is only
> present for the AR3011 devices with SFLASH configuration.
Most likely including the flashing into ath3k firmware loading driver
and that being called bound twice might be a good idea. However we are
not doing the firmware loading in btusb. Then a patch to blacklist this
broken device. And then ensure that the firmware changes the USB PIDs
after success.
And if I understand you correct, then it does this anyway right now
already. Otherwise the ath3k driver would not bind to it.
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.
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.
Regards
Marcel
Hi Matthew,
> > Right -- so ath3k depends on some atheros USB device IDs, and its a
> > stupid driver that just loads firmware. The problem with this new
> > device is that it requires two phases. One to load some sort of
> > firmware onto it to get it to read as an ath3k device, and then ath3k
> > will load the right firmware to it. So the hardware device is already
> > claiming a btusb vendor:device ID, we can't change that I believe. Of
> > course for future devices we can, and we've addressed this and its
> > been fixed.
>
> If the device IDs can be changed when the firmware is loaded, then
> simply provide a driver that binds to the original IDs and uploads the
> firmware. The original IDs can be blacklisted from btusb so it won't
> interfere. The device will then boot the firmware, detach and reattach
> with new IDs - btusb will then bind. Repeat for every cold reset.
>
> If you can't change the IDs from firmware then an alternative would be
> to blacklist it from btusb and provide a userspace application triggered
> by a udev rule. Have it load the firmware and then poke
> /sys/bus/usb/drivers/btusb/new_id .
exactly, we just blacklist the original USB IDs in the btusb driver. It
already has a blacklist table and you just use BTUSB_IGNORE in there.
Regards
Marcel
On Tue, Oct 05, 2010 at 01:28:53PM -0700, Luis R. Rodriguez wrote:
> Right -- so ath3k depends on some atheros USB device IDs, and its a
> stupid driver that just loads firmware. The problem with this new
> device is that it requires two phases. One to load some sort of
> firmware onto it to get it to read as an ath3k device, and then ath3k
> will load the right firmware to it. So the hardware device is already
> claiming a btusb vendor:device ID, we can't change that I believe. Of
> course for future devices we can, and we've addressed this and its
> been fixed.
If the device IDs can be changed when the firmware is loaded, then
simply provide a driver that binds to the original IDs and uploads the
firmware. The original IDs can be blacklisted from btusb so it won't
interfere. The device will then boot the firmware, detach and reattach
with new IDs - btusb will then bind. Repeat for every cold reset.
If you can't change the IDs from firmware then an alternative would be
to blacklist it from btusb and provide a userspace application triggered
by a udev rule. Have it load the firmware and then poke
/sys/bus/usb/drivers/btusb/new_id .
--
Matthew Garrett | [email protected]
On Tue, Oct 5, 2010 at 12:58 PM, Marcel Holtmann
<[email protected]> wrote:
> Hi Luis,
>
>> > > Marcel, I was just poked about this thread:
>> > >
>> > > http://www.spinics.net/lists/linux-bluetooth/msg06087.html
>> > >
>> > > The hack is required because our BT hardware does not accept HCI commands
>> > > when the device is plugged in. If I understood your position you did not
>> > > want to accept the patch because our BT USB devices are violating the
>> > > specification by not acceping HCI commands and yet claiming to be BT
>> > > devices, is that right?
>> >
>> > you don't have to accept HCI commands when your device has no firmware
>> > loaded. That is just fine. However at that point you should not claim to
>> > be a Bluetooth H:2 device with USB Bluetooth descriptors.
>> >
>> > Just having different USB PIDs for without firmware and with firmware
>> > stages would have been fine. The ancient Broadcom 203x devices even got
>> > that part right.
>>
>> Ah I see.
>>
>> > So what about sticking with the current VID:PID for the device without
>> > firmware and we blacklist it in btusb driver. And then the firmware
>> > loading ensures that after reset it uses a different PID for the device
>> > with valid HCI firmware.
>>
>> How would firmware be uploaded to the device if no module
>> is claiming it?
>
> most likely via a separate firmware loading driver.
Like the fwload patch ? Or something different?
> Your ath3k driver is such a driver. Same as the bcm203x driver.
Right -- so ath3k depends on some atheros USB device IDs, and its a
stupid driver that just loads firmware. The problem with this new
device is that it requires two phases. One to load some sort of
firmware onto it to get it to read as an ath3k device, and then ath3k
will load the right firmware to it. So the hardware device is already
claiming a btusb vendor:device ID, we can't change that I believe. Of
course for future devices we can, and we've addressed this and its
been fixed.
> They don't do anything than claiming that USB device, loading the firmware, and then let it reset.
Right but if the SFLASH configurations hardware is already shipping
and without firmware is claiming to be a BT USB device which matches
the USB vendor:device ID of the btusb driver. Unfortunately it does
not accept HCI commands which as you indicates breaks some
specification. We can and have fixed this in future chipsets but this
one cannot be addressed. So what do we do?
> And after the reset the btusb can claim the one where the firmware has
> been loaded and which behaves like a proper USB dongle.
Right, that's what the fwload patch from our BT team does, no?
> The part that I don't understand is that you have the ath3k driver doing
> it exactly how it should be done, why now started to make nasty hacks in
> the btusb driver.
Yeah that seems to have been a shortcoming, its something you should
expect from us moving forward. I've been told AR3012 and future
Atheros chipsets will not have behave this way, and this issue is only
present for the AR3011 devices with SFLASH configuration.
Luis
Hi Luis,
> > > Marcel, I was just poked about this thread:
> > >
> > > http://www.spinics.net/lists/linux-bluetooth/msg06087.html
> > >
> > > The hack is required because our BT hardware does not accept HCI commands
> > > when the device is plugged in. If I understood your position you did not
> > > want to accept the patch because our BT USB devices are violating the
> > > specification by not acceping HCI commands and yet claiming to be BT
> > > devices, is that right?
> >
> > you don't have to accept HCI commands when your device has no firmware
> > loaded. That is just fine. However at that point you should not claim to
> > be a Bluetooth H:2 device with USB Bluetooth descriptors.
> >
> > Just having different USB PIDs for without firmware and with firmware
> > stages would have been fine. The ancient Broadcom 203x devices even got
> > that part right.
>
> Ah I see.
>
> > So what about sticking with the current VID:PID for the device without
> > firmware and we blacklist it in btusb driver. And then the firmware
> > loading ensures that after reset it uses a different PID for the device
> > with valid HCI firmware.
>
> How would firmware be uploaded to the device if no module
> is claiming it?
most likely via a separate firmware loading driver. Your ath3k driver is
such a driver. Same as the bcm203x driver. They don't do anything than
claiming that USB device, loading the firmware, and then let it reset.
And after the reset the btusb can claim the one where the firmware has
been loaded and which behaves like a proper USB dongle.
The part that I don't understand is that you have the ath3k driver doing
it exactly how it should be done, why now started to make nasty hacks in
the btusb driver.
Regards
Marcel
On Tue, Oct 05, 2010 at 01:23:01AM -0700, Marcel Holtmann wrote:
> Hi Luis,
>
> > Marcel, I was just poked about this thread:
> >
> > http://www.spinics.net/lists/linux-bluetooth/msg06087.html
> >
> > The hack is required because our BT hardware does not accept HCI commands
> > when the device is plugged in. If I understood your position you did not
> > want to accept the patch because our BT USB devices are violating the
> > specification by not acceping HCI commands and yet claiming to be BT
> > devices, is that right?
>
> you don't have to accept HCI commands when your device has no firmware
> loaded. That is just fine. However at that point you should not claim to
> be a Bluetooth H:2 device with USB Bluetooth descriptors.
>
> Just having different USB PIDs for without firmware and with firmware
> stages would have been fine. The ancient Broadcom 203x devices even got
> that part right.
Ah I see.
> So what about sticking with the current VID:PID for the device without
> firmware and we blacklist it in btusb driver. And then the firmware
> loading ensures that after reset it uses a different PID for the device
> with valid HCI firmware.
How would firmware be uploaded to the device if no module
is claiming it?
Luis
Hi Luis,
> Marcel, I was just poked about this thread:
>
> http://www.spinics.net/lists/linux-bluetooth/msg06087.html
>
> The hack is required because our BT hardware does not accept HCI commands
> when the device is plugged in. If I understood your position you did not
> want to accept the patch because our BT USB devices are violating the
> specification by not acceping HCI commands and yet claiming to be BT
> devices, is that right?
you don't have to accept HCI commands when your device has no firmware
loaded. That is just fine. However at that point you should not claim to
be a Bluetooth H:2 device with USB Bluetooth descriptors.
Just having different USB PIDs for without firmware and with firmware
stages would have been fine. The ancient Broadcom 203x devices even got
that part right.
So what about sticking with the current VID:PID for the device without
firmware and we blacklist it in btusb driver. And then the firmware
loading ensures that after reset it uses a different PID for the device
with valid HCI firmware.
Regards
Marcel
On Tue, Oct 12, 2010 at 6:38 AM, Kevin Hayes <[email protected]> wrote:
> Yes, it is a good idea to let the downloadable firmware set a new PID, along with the
> blacklist on the 3002 PID for the first go round. I emphasize, it is the downloaded
> firmware that will be required to do the PID swizzling, not the sflash firmware. And I
> agree we should have a map of the PIDs in use and what they are used for, once
> we get through this immediate fixing phase.
FWIW, since we actually have customers already using this I took
Bala's original patch and put it into compat-wirelesss-2.6.36 and the
current bleeding edge compat-wireless so we can get customers at least
something working in the mean time. Of course this means we'll need to
support this patch should any issues come up ;).
The proper patch didn't make it to 2.6.37, hoping this will get
resolved for 2.6.38.
Luis
Hi Marcel,
On 10/7/2010 10:05 PM, Bala Shanmugam wrote:
> On 10/7/2010 8:54 PM, Marcel Holtmann wrote:
>> Hi Bala,
>>
>>> Thanks Johannes. This would be better option to change PID in firmware
>>> as blacklisting 3002 might create problems for 3011 chipsets.
>>> Will try and let you people know.
>> The misbehaving 3002 needs to be blacklisted in btusb.c anyway. However
>> after loading the firmware to 3002 device, it should change its PID to
>> something else.
>>
>> I am still trying to figure out if this is one stage firmware loading or
>> a two stage firmware loading. This is all pretty unclear and nobody has
>> answered this clearly so far.
>>
>> Regards
>>
>> Marcel
>>
>>
> Marcel,
>
> eeprom based 3011 chips comes up with PID 3000 giving control to DFU
> driver [ath3k]. ath3k downloads the
> firmware changing PID to 3002. Now btusb gets control.
>
> In sflash based devices to reduce windows suspend/resume time we had a
> small firmware in flash which
> enables the device to get detected as Generic Bluetooth USB device with
> PID 3002. So control reaches btusb when device is plugged in, leaving
> no option for us to load the actual firmware.
>
> Solution would be to blacklist 3002 in btusb, enable ath3k to get
> control for both the devices, download the firmware and change PID to
> 3003 so that control with come to btusb.
>
> Thanks for your time.
>
> Regards,
> Bala.
As you suggested we blacklisted PID 3002 in btusb and loaded firmware
using ath3k and it worked.
Thanks.
Many of our customers are using their own PIDs and blacklisting 3002
won't work for them.
Can we blacklist all the PIDs used by different customers?
We have another device similar to above one, it doesn't do a USB reset
after downloading firmware.
This is basically to reduce bring-up and suspend/resume time.
Can we add an infrastructure in btusb to download configuration or
firmware for these devices?
If not can you please suggest a solution for this device.
Thanks in advance.
Regards,
Bala.