On Mon, 5 Apr 2010, Dominik Brodowski wrote:
> 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.
Hmm. Maybe usb_driver_claim_interface() should be changed. Since the
probe routine never gets called for a claimed interface, it would make
sense that the interface should start out in a suspended state. So
maybe claim_interface should call pm_runtime_set_suspended() instead of
pm_runtime_set_active().
Oliver, do you know if this issue has come up before?
> 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...
That's a new problem. Does the device get autoresumed correctly? If
yes, then where does the failure occur?
Alan Stern
--
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
