Wakeup settings for USB hubs?

Wakeup settings for USB hubs?

[Alan Stern]

Here's a question that has been bothering me for a while.  Should we 
enable remote wakeup on USB hubs?

On the face of it the answer is obviously Yes.  And certainly we want
remote wakeup enabled during a runtime suspend; otherwise the system
would never know when the user unplugged a device from the hub or
plugged in a new one.

But consider STR, say in the case of a laptop with a USB mouse
attached.  The user suspends the laptop.  Then he prepares to pack it
away and in the process unplugs the mouse.  Pow! -- the laptop
springs back to life.  That's not what we want.

On the other hand, the user might indeed want to awaken the laptop by
clicking the USB mouse.  So what should we do?  The question is made
even more difficult by the fact that, if the hub is already
runtime-suspended when the system suspend occurs, we would have to
resume the hub just in order to turn off remote wakeup!

Right now we more or less ignore all these issues by relying on the 
wakeup settings in sysfs.  Is that a reasonable approach?  Is there 
anything else we can do?

Alan Stern

Re: Wakeup settings for USB hubs?

[Oliver Neukum]

Am Mittwoch, 4. Juli 2007 schrieb Alan Stern:
> Here's a question that has been bothering me for a while.  Should we 
> enable remote wakeup on USB hubs?
> 
> On the face of it the answer is obviously Yes.  And certainly we want
> remote wakeup enabled during a runtime suspend; otherwise the system
> would never know when the user unplugged a device from the hub or
> plugged in a new one.

I agree. Runtime suspend needs remote wakeup.

> But consider STR, say in the case of a laptop with a USB mouse
> attached.  The user suspends the laptop.  Then he prepares to pack it
> away and in the process unplugs the mouse.  Pow! -- the laptop
> springs back to life.  That's not what we want.

We might want attaching a device to wake the laptop. OR we might
not. The choice is not makeable in kernel space.

> On the other hand, the user might indeed want to awaken the laptop by
> clicking the USB mouse.  So what should we do?  The question is made
> even more difficult by the fact that, if the hub is already
> runtime-suspended when the system suspend occurs, we would have to
> resume the hub just in order to turn off remote wakeup!

I don't think this can be helped. We cannot leave the setting of remote
wakeup in the STR case to chance. We'd do so if we let stand the setting
caused by autosuspend.
If that means waking up a hub about to be suspended again, so be it.

> Right now we more or less ignore all these issues by relying on the 
> wakeup settings in sysfs.  Is that a reasonable approach?  Is there 
> anything else we can do?

I don't think so. It is the most reasonable approach.

	Regards
		Oliver

Re: Wakeup settings for USB hubs?

[Zhang Rui]

On Wed, 2007-07-04 at 14:43 -0400, Alan Stern wrote:
> Here's a question that has been bothering me for a while.  Should we 
> enable remote wakeup on USB hubs?
> 
> On the face of it the answer is obviously Yes.  And certainly we want
> remote wakeup enabled during a runtime suspend; otherwise the system
> would never know when the user unplugged a device from the hub or
> plugged in a new one.
> 
> But consider STR, say in the case of a laptop with a USB mouse
> attached.  The user suspends the laptop.  Then he prepares to pack it
> away and in the process unplugs the mouse.  Pow! -- the laptop
> springs back to life.  That's not what we want.
> 
> On the other hand, the user might indeed want to awaken the laptop by
> clicking the USB mouse.  So what should we do?  The question is made
> even more difficult by the fact that, if the hub is already
> runtime-suspended when the system suspend occurs, we would have to
> resume the hub just in order to turn off remote wakeup!
> 
> Right now we more or less ignore all these issues by relying on the 
> wakeup settings in sysfs.  Is that a reasonable approach?  Is there 
> anything else we can do?
> 

IMO, device runtime wakeup and wakeup from a system sleep state are
different.
If we want to make use of the wakeup setting in sysfs, we can't simply
enable/disable /sys/.../power/wakeup.

Some different values like "device_runtime" and "system_sleep" are
needed to indicate the different remote wakeup state.
Take ACPI platform for example:
"disable":		disable remote wakeup.
"device_runtime":	device runtime wakeup is enabled, while device 
			can not wakeup the system from a sleep state.
			For ACPI platforms, that's disable the wakeup
			GPE of the device.
"system_sleep":		the ability of wakeup system from a sleep state
			is enabled. It needs to enable the device
			runtime wakeup ability first. and enable wakeup
			GPE as well for ACPI platforms.

All the platform specific operations can be done in the
platform_enable_wakeup hook.
All the remote wakeup state are set to device_runtime by default.
We can set the ../power/state to "system_sleep" when we want to wakeup
the system from STR by clicking the USB mouse. :)

Thanks,
Rui

Re: Wakeup settings for USB hubs?

[Alan Stern]

On Thu, 5 Jul 2007, Zhang Rui wrote:

> IMO, device runtime wakeup and wakeup from a system sleep state are
> different.

I sort of agree with you.  (Except that on smaller or embedded systems, 
there isn't always such a clear distinction between runtime suspend and 
system suspend.  One sort of blends into the other as more and more 
components are powered down.  But let's ignore that.)

> If we want to make use of the wakeup setting in sysfs, we can't simply
> enable/disable /sys/.../power/wakeup.
> 
> Some different values like "device_runtime" and "system_sleep" are
> needed to indicate the different remote wakeup state.
> Take ACPI platform for example:
> "disable":		disable remote wakeup.
> "device_runtime":	device runtime wakeup is enabled, while device 
> 			can not wakeup the system from a sleep state.
> 			For ACPI platforms, that's disable the wakeup
> 			GPE of the device.
> "system_sleep":		the ability of wakeup system from a sleep state
> 			is enabled. It needs to enable the device
> 			runtime wakeup ability first. and enable wakeup
> 			GPE as well for ACPI platforms.

Allow me to rephrase.  You seem to be saying that /sys/.../power/wakeup 
should be able to hold four different values:

	1. always disabled
	2. always enabled
	3. enabled at runtime but not during system sleep
	4. enabled during system sleep but not at runtime

Right?  With the default being 3 (except for a few things like the 
power button).

Or maybe there should be two attribute files: wakeup (used during
system sleep) and wakeup_runtime (used for runtime suspend).

Comments from anybody else?

Alan Stern

Re: Wakeup settings for USB hubs?

[Rafael J. Wysocki]

On Thursday, 5 July 2007 17:01, Alan Stern wrote:
> On Thu, 5 Jul 2007, Zhang Rui wrote:
> 
> > IMO, device runtime wakeup and wakeup from a system sleep state are
> > different.
> 
> I sort of agree with you.  (Except that on smaller or embedded systems, 
> there isn't always such a clear distinction between runtime suspend and 
> system suspend.  One sort of blends into the other as more and more 
> components are powered down.  But let's ignore that.)
> 
> > If we want to make use of the wakeup setting in sysfs, we can't simply
> > enable/disable /sys/.../power/wakeup.
> > 
> > Some different values like "device_runtime" and "system_sleep" are
> > needed to indicate the different remote wakeup state.
> > Take ACPI platform for example:
> > "disable":		disable remote wakeup.
> > "device_runtime":	device runtime wakeup is enabled, while device 
> > 			can not wakeup the system from a sleep state.
> > 			For ACPI platforms, that's disable the wakeup
> > 			GPE of the device.
> > "system_sleep":		the ability of wakeup system from a sleep state
> > 			is enabled. It needs to enable the device
> > 			runtime wakeup ability first. and enable wakeup
> > 			GPE as well for ACPI platforms.
> 
> Allow me to rephrase.  You seem to be saying that /sys/.../power/wakeup 
> should be able to hold four different values:
> 
> 	1. always disabled
> 	2. always enabled
> 	3. enabled at runtime but not during system sleep
> 	4. enabled during system sleep but not at runtime
> 
> Right?  With the default being 3 (except for a few things like the 
> power button).
> 
> Or maybe there should be two attribute files: wakeup (used during
> system sleep) and wakeup_runtime (used for runtime suspend).

I like the last idea.

I think that, at least for now, we shouldn't mix the runtime power management
with entering the system sleep states.  Of course on the low level it may be
possible to use the same code for suspending the device regardless of the
purpose, but on the high level mixing the two things often leads to confusion.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth

Re: Wakeup settings for USB hubs?

[Oliver Neukum]

Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> Allow me to rephrase.  You seem to be saying that /sys/.../power/wakeup 
> should be able to hold four different values:
> 
>         1. always disabled
>         2. always enabled
>         3. enabled at runtime but not during system sleep
>         4. enabled during system sleep but not at runtime
> 
> Right?  With the default being 3 (except for a few things like the 
> power button).
> 
> Or maybe there should be two attribute files: wakeup (used during
> system sleep) and wakeup_runtime (used for runtime suspend).
> 
> Comments from anybody else?

I am not sure we ever want to do runtime suspend without remote wakeup.
If we want that then it is orthogonal to its value during system sleep.
That would call for two attributes.

	Regards
		Oliver

Re: Wakeup settings for USB hubs?

[Alan Stern]

On Thu, 5 Jul 2007, Oliver Neukum wrote:

> Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> > Allow me to rephrase.  You seem to be saying that /sys/.../power/wakeup 
> > should be able to hold four different values:
> > 
> >         1. always disabled
> >         2. always enabled
> >         3. enabled at runtime but not during system sleep
> >         4. enabled during system sleep but not at runtime
> > 
> > Right?  With the default being 3 (except for a few things like the 
> > power button).
> > 
> > Or maybe there should be two attribute files: wakeup (used during
> > system sleep) and wakeup_runtime (used for runtime suspend).
> > 
> > Comments from anybody else?
> 
> I am not sure we ever want to do runtime suspend without remote wakeup.

You mean the user shouldn't be able to disable remote wakeup during a
runtime suspend?  But what if the user wants to put the device to sleep
with no possibility of wakeup?

> If we want that then it is orthogonal to its value during system sleep.
> That would call for two attributes.

Another attribute can be added easily enough.

Dave, you created the original wakeup attribute.  What do you think 
about adding a separate wakeup_runtime?  (At a minimum, perhaps you can 
suggest a better name!)

Alan Stern

Re: Wakeup settings for USB hubs?

[Oliver Neukum]

Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> On Thu, 5 Jul 2007, Oliver Neukum wrote:
> 
> > Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> > > Allow me to rephrase.  You seem to be saying that /sys/.../power/wakeup 
> > > should be able to hold four different values:
> > > 
> > >         1. always disabled
> > >         2. always enabled
> > >         3. enabled at runtime but not during system sleep
> > >         4. enabled during system sleep but not at runtime
> > > 
> > > Right?  With the default being 3 (except for a few things like the 
> > > power button).
> > > 
> > > Or maybe there should be two attribute files: wakeup (used during
> > > system sleep) and wakeup_runtime (used for runtime suspend).
> > > 
> > > Comments from anybody else?
> > 
> > I am not sure we ever want to do runtime suspend without remote wakeup.
> 
> You mean the user shouldn't be able to disable remote wakeup during a
> runtime suspend?  But what if the user wants to put the device to sleep
> with no possibility of wakeup?

Then the user will have to force suspend anyway and we can use the existing
attribute. Two points:

1. For hubs I don't think we should allow it
2. The important distinction is not between system wide vs. device,
but between forced sleep and the "best effort" runtime suspension
in style of autosuspend. The latter needs remote wakeup under control
of the driver.

	Regards
		Oliver

Re: Wakeup settings for USB hubs?

[Alan Stern]

On Thu, 5 Jul 2007, Oliver Neukum wrote:

> > > I am not sure we ever want to do runtime suspend without remote wakeup.
> > 
> > You mean the user shouldn't be able to disable remote wakeup during a
> > runtime suspend?  But what if the user wants to put the device to sleep
> > with no possibility of wakeup?
> 
> Then the user will have to force suspend anyway and we can use the existing
> attribute. Two points:
> 
> 1. For hubs I don't think we should allow it

Why not?

> 2. The important distinction is not between system wide vs. device,
> but between forced sleep and the "best effort" runtime suspension
> in style of autosuspend. The latter needs remote wakeup under control
> of the driver.

The existing USB code already takes this into account.  For "best 
effort" runtime autosuspend, if the driver wants remote wakeup 
capability and the user has disabled it (or the device doesn't provide 
it) then the autosuspend will fail.  However "forced" runtime 
suspension will succeed regardless of whether wakeup is enabled.

Alan Stern

Re: Wakeup settings for USB hubs?

[David Brownell]

On Thursday 05 July 2007, Alan Stern wrote:

> Dave, you created the original wakeup attribute.  What do you think 
> about adding a separate wakeup_runtime?  (At a minimum, perhaps you can 
> suggest a better name!)

I'll have to scan the emails in my queue to see what the issue
is (umm, is this really 300+ messages in just the last couple
days??) but my initial reaction is to avoid complications.  We
have enough configuration knobs ... but userspace hasn't even
begun to use them.  Adding more knobs will not improve that
situation at all.

At one level, we want USB mice and keyboards to act pretty much
like the PS2 variety.  Which means being wakeup sources in most
cases ... though BIOS settings often overrides the PS2 stuff.

It'd make sense that _removing_ devices not normally be a wake
event for USB ports.  But we don't always have that option...

- Dave

Re: Wakeup settings for USB hubs?

[Zhang Rui]

Hi,
No one interested in this topic?
I thought it might be hot. :)

On Fri, 2007-07-06 at 05:30 +0800, David Brownell wrote:
> On Thursday 05 July 2007, Alan Stern wrote:
> 
> > Dave, you created the original wakeup attribute.  What do you think
> > about adding a separate wakeup_runtime?  (At a minimum, perhaps you
> can
> > suggest a better name!)
I think it's reasonable.

> I'll have to scan the emails in my queue to see what the issue
> is (umm, is this really 300+ messages in just the last couple
> days??) but my initial reaction is to avoid complications.  We
> have enough configuration knobs ... but userspace hasn't even
> begun to use them.  Adding more knobs will not improve that
> situation at all.
Well, I can not find one for the system sleep wakeup attribute,
I mean the ability to wakeup the system from a sleep state.
The patch http://www.spinics.net/lists/mm-commits/msg27356.html
makes the "wakeup" from device runtime suspend and the "wakeup" from
system suspend both controlled by .../power/wakeup.
This doesn't work in some cases, and that's why the patch
http://www.spinics.net/lists/mm-commits/msg30526.html are dropped.

I think we should find an alternative way instead of
using .../power/wakeup.
Another wakeup file or more values in the .../power/wakeup makes sense
to me, while the first one seems better. :)

Dave, what's you opinion?
Are there any available knobs that we can make use of but I missed?

Thanks,
Rui

> At one level, we want USB mice and keyboards to act pretty much
> like the PS2 variety.  Which means being wakeup sources in most
> cases ... though BIOS settings often overrides the PS2 stuff.
> 
> It'd make sense that _removing_ devices not normally be a wake
> event for USB ports.  But we don't always have that option...