Re: [PATCH v2 09/14] PM / Runtime: hold device active during device_wakeup_{enable|disable}

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/23/2013 1:16 AM, Dan Williams wrote:
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.

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 rjw@xxxxxxxxxxxxx (ie. me)?

Rafael

--
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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux