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?
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 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)?
Rafael
--
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
