Return-Path: Subject: Re: RFC: btusb firmware load help From: Marcel Holtmann To: Matthew Garrett Cc: "Luis R. Rodriguez" , Luis Rodriguez , linux-bluetooth , "linux-kernel@vger.kernel.org" , "linux-wireless@vger.kernel.org" , Deepak Dhamdhere , Sree Durbha In-Reply-To: <20101005215008.GA11117@srcf.ucam.org> References: <20100924230730.GB6566@tux> <1286266981.17473.33.camel@aeonflux> <20101005192814.GB11831@tux> <1286308731.2588.13.camel@aeonflux> <20101005215008.GA11117@srcf.ucam.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Oct 2010 09:09:25 +0200 Message-ID: <1286348965.6145.1.camel@aeonflux> Mime-Version: 1.0 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Matthew, > > 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 . exactly, we just blacklist the original USB IDs in the btusb driver. It already has a blacklist table and you just use BTUSB_IGNORE in there. Regards Marcel