Am Montag, 5. April 2010 22:55:08 schrieb Alan Stern: > 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 Yes. > 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(). Yes, though ideally we wouldn't make an attempt to autosuspend an interface a driver that does not support autosuspend has claimed. > Oliver, do you know if this issue has come up before? No, this is new. I suspect behavior has been changed by the switch to the generic framework. > > 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? Exactly. CONFIG_USB_DEBUG should help in discovering what goes wrong. Regards Oliver -- 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
