On Tue, 28 May 2013, Julius Werner wrote: > The policy we want to achieve is to disable runtime PM iff there is a > device connected that doesn't have persist_enabled or a reset_resume() > handler and whose parent/root hub resets on resume, right? So couldn't Probably just root hub, not parent. A non-root hub that resets upon resume wouldn't be a good idea. Also, we know in advance that the hub driver _does_ have a reset-resume handler. > we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing) > generic USB_QUIRK_RESET_RESUME on the root hub instead? Then we could > handle all of this in the USB core (during device initialization and > when changing persist_enabled through sysfs) by just checking for > udev->reset_resume on all parent hubs of the device in question (and > use pm_runtime_get/put() on said device to prevent its parents from > suspending as appropriate). This sounds too intricate to me. You might want to prevent resets even if the device does support reset-resume, because they consume time. Or you might not care about resets even if persist isn't enabled (consider a USB mouse, for example). I agree that setting the RESET_RESUME quirk on the root hub is a good way to represent the situation. And perhaps the kernel could implement a useful default policy -- but userspace should ultimately remain in control. 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
