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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
