lkml.org 
[lkml]   [2010]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: RFC: btusb firmware load help
    On Tue, Oct 5, 2010 at 12:58 PM, Marcel Holtmann
    <holtmann@linux.intel.com> 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


    \
     
     \ /
      Last update: 2010-10-05 22:33    [W:4.285 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site