On Fri, Nov 22, 2013 at 4:06 PM, Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> wrote: > On 11/22/2013 8:29 PM, Dan Williams wrote: >> >> On Fri, Nov 22, 2013 at 7:50 AM, Rafael J. Wysocki >> <rafael.j.wysocki@xxxxxxxxx> 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 <rafael.j.wysocki@xxxxxxxxx> >>>> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> >>> >>> >>> 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. -- 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
