Re: RFC: btusb firmware load help

[Luis R. Rodriguez]

On Tue, Oct 5, 2010 at 12:58 PM, Marcel Holtmann
<holtmann@xxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/