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