Return-Path: Date: Tue, 5 Oct 2010 12:28:14 -0700 From: "Luis R. Rodriguez" To: Marcel Holtmann CC: Luis Rodriguez , linux-bluetooth , "linux-kernel@vger.kernel.org" , "linux-wireless@vger.kernel.org" , Deepak Dhamdhere , Sree Durbha Subject: Re: RFC: btusb firmware load help Message-ID: <20101005192814.GB11831@tux> References: <20100924230730.GB6566@tux> <1286266981.17473.33.camel@aeonflux> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <1286266981.17473.33.camel@aeonflux> Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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