linux-kernel - Re: RFC: btusb firmware load help

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 05 Oct 2010 21:58:51 +0200
From:	Marcel Holtmann <holtmann@...ux.intel.com>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	linux-bluetooth <linux-bluetooth@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	Deepak Dhamdhere <Deepak.Dhamdhere@...eros.com>,
	Sree Durbha <Sree.Durbha@...eros.com>
Subject: Re: RFC: btusb firmware load help

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/