On Fri, Nov 22, 2013 at 4:27 PM, Rafael J. Wysocki <[email protected]> wrote: > On 11/23/2013 1:16 AM, Dan Williams wrote: >> >> On Fri, Nov 22, 2013 at 4:06 PM, Rafael J. Wysocki >> <[email protected]> wrote: >>> >>> On 11/22/2013 8:29 PM, Dan Williams wrote: >>>> >>>> On Fri, Nov 22, 2013 at 7:50 AM, Rafael J. Wysocki >>>> <[email protected]> wrote: >>>>> >>>>> On 11/22/2013 10:08 AM, Dan Williams wrote: >>>>>> >>>>>> usbcore blocks powering off hub ports while a downstream source is >>>>>> wakeup enabled. Once wakeup is disabled usbcore can try again to turn >>>>>> off the parent port. Add a pm_runtime reference manipulation to retry >>>>>> a >>>>>> port power down on disable, or pin the port active on enable. >>>>>> >>>>>> Cc: Rafael J. Wysocki <[email protected]> >>>>>> Signed-off-by: Dan Williams <[email protected]> >>>>> >>>>> >>>>> Well, while this generally won't hurt, I'm not sure how it helps >>>>> either, >>>>> because device_(disable|enable)_wakeup() don't touch any hardware and >>>>> (for >>>>> now) they are only about wakeup from system suspend. >>>>> >>>> If a USB device's parent port is turned off prior to system suspend >>>> then remote wakeup will be blocked. >>> >>> >>> Do you mean it won't wake up from system suspend? Or something else? >>> >> The former, remote wakeup from system suspend will fail if the parent >> port is disabled. >> >>>> We could handle this internally >>>> by correcting the setting at suspend time, but would need to wake the >>>> port and possibly recover the connection to suspend. Just seemed >>>> cleaner to notify the setting change. >>> >>> >>> I'm not sure I understand you correctly. >>> >>> So you want your .runtime_resume() callback to be executed when the >>> system >>> wakeup setting is changed so that you know that it has been changed? Or >>> do >>> you mean something different? >>> >> Correct, want this device and its parent port to notice the change. > > > But your change will affect all devices, not only USB. Why do you think > this is appropriate? >
It seemed to me to make sense to have a device topology runtime active while configuring remote wakeup, but maybe there's a better way. I was thinking it was analogous to dev_pm_qos_update_flags(). > Moreover, your .runtime_resume() callback may be executed for different > reasons I suppose. Do you want to check the wakeup status every time it is > executed? And what happens if user space writes "on" to the device's > power/control file, in which case your .runtime_resume() callback won't be > executed at all from device_set_wakeup_enable()? I only want to evaluate this status in the .runtime_suspend() of the parent device (usb port device). When that runs I want to check the status and leave the port active if the child device will trigger wakeup. > I think you are trying to work around an issue with the kernel's wakeup > infrastructure that there is no direct coordination between runtime remote > wakeup and system wakeup (from suspend). > > Can you please file a bug at bugzilla.kernel.org against "power management" > describing what the problem is and assign it to [email protected] (ie. me)? > Sure, I can do that. Should be able to trigger this bug in current mainline. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
