Okay, this was probably the most difficult issue I've ever hunted down: In it's probe callback (1:0), btusb.c calls usb_driver_claim_interface() for a different interface (1:1). The USB driver core then activates runtime_suspend for this other interface (1:1), which means the parent usb device children_count is increased by one. However, for this other interface (1:1), there's a problem: nobody ever tries to runtime-suspend it, even though it's usage count is 0. diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 5d9cc53..5056424 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -1010,6 +1010,9 @@ static int btusb_probe(struct usb_interface *intf, hci_free_dev(hdev); kfree(data); return err; + } else { + if (!usb_autopm_get_interface(data->isoc)) + usb_autopm_put_interface(data->isoc); } } allows for auto-suspending btusb once hci0 is down. The only problem: "hciconfig hci0 up" fails to get the device to an useable state again, even if I disable autosuspend again... Best, Dominik -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html