Re: RFC: btusb firmware load help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx
--
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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux