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, 5 Oct 2010 22:50:08 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	Marcel Holtmann <holtmann@...ux.intel.com>,
	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

On Tue, Oct 05, 2010 at 01:28:53PM -0700, Luis R. Rodriguez wrote:

> 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.

If the device IDs can be changed when the firmware is loaded, then 
simply provide a driver that binds to the original IDs and uploads the 
firmware. The original IDs can be blacklisted from btusb so it won't 
interfere. The device will then boot the firmware, detach and reattach 
with new IDs - btusb will then bind. Repeat for every cold reset.

If you can't change the IDs from firmware then an alternative would be 
to blacklist it from btusb and provide a userspace application triggered 
by a udev rule. Have it load the firmware and then poke 
/sys/bus/usb/drivers/btusb/new_id .

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/