On Mon, 26 Feb 2007, Oliver Neukum wrote:
> Am Montag, 26. Februar 2007 18:37 schrieb Alan Stern:
> > > - don't do an immediate suspend independent of autosuspend
> >
> > Why not? In extreme cases the user can force an immediate suspend by
> > doing suspend-to-RAM anyway. This merely preserves the capability we are
> > about to lose when the power/state attribute disappears completely.
>
> Arent we removing that attribute among other things precisely because
> this capability violates the power tree requirements?
Not really. Drivers always have the ability to fail a suspend if their
children aren't already suspended. The hub driver checks for that, for
instance, and so do the host controller drivers.
> > > > Add a new power/suspended attribute. Writing 1 will always try to
> > > > suspend
> > > > immediately (_not_ an autosuspend!) and writing 0 will always resume
> > > > immediately (but will start the autosuspend timer).
> > >
> > > This is problematic, as it is a totally new code path.
> >
> > No it isn't. It's the code path used for traditional
> > suspend-to-{RAM,disk} and also used by power/state.
>
> STR/D freeeze user space, thus making additional guarantees we wouldn't
> meet. power/state is being obsoleted.
We can't meet those additional guarantees when doing an autosuspend
either.
The main reason for deprecating power/state was that it did not have the
necessary expressive power. Different buses have different sets of power
states and requirements (sometimes individual devices do too), but
power/state only allowed for 0, 1, 2, or 3.
And the fact remains even though power/state is deprecated, its code
paths are old, not new.
> > > > BTW, note that an autosuspend request is different from a plain old
> > > > suspend request. Autosuspend will fail if an interface requires
> > > > remote-wakeup capability but remote wakeup is disabled, whereas a
> > > > regular
> > > > suspend won't fail.
> > >
> > > Yes, that too. It makes that even more asymmetric. We wake up on demand
> > > in only one direction.
> >
> > I don't know what you mean. We _always_ wake up on demand. What's
> > asymmetrical about that?
>
> We wake up for output. We suspend even if we can't wake up for input.
That goes back to the issue mentioned earlier: We cannot refuse to do a
suspend merely because remote wakeup isn't enabled -- it would break
swsusp.
The user has the ability to enable or disable remote wakeup through the
power/wakeup attribute. Suppose for some reason the user has decided to
disable remote wakeup -- maybe because he really wants the device to
remain suspended. Are you trying to say that the kernel should then
prevent the user from suspending the device at all?
> > No. One more time:
> >
> > WE ALWAYS WAKE UP ON DEMAND!
>
> Why? Repeating the assertion doesn't make it any more logical.
What's illogical about always waking up on demand?
> > If the user really wants a device to suspend and not wake up, he can take
> > more drastic action. Just don't send it any more demands. Unbind it from
> > its driver. Unplug it -- and that would save even more power!
>
> (Apart from the interesting question of how to unplug a touchpad built
> into a laptop)
(Unbinding it from its driver will work. Disabling remote wakeup and
forcing a suspend will also work, provided no user tasks then try to
access the touchpad.)
> If we want that, than again I don't see why you want to suspend "in between"
> autosuspend and full system suspend. It should be enough to suspend
> immediately if the driver has agreed to autosuspension.
There's a big difference you are ignoring: Autosuspend occurs when the
_driver_ thinks it should happen. But suspend occurs when the _user_
thinks it should happen.
Now there's nothing wrong with providing parameters to the driver,
advising it when it should or should not autosuspend. But if the user
wants to do something, the driver should not go out of its way to prevent
it.
> > The kernel's opinion about whether a device should be autosuspended _is_
> > exported through the power/autosuspend attribute. Values > 0 mean yes (or
> > >= 0 after I change it), other values mean no.
>
> That seems almost deliberately obfuscated.
> One file, one value, one meaning.
> (sounds vaguely like a song by Queen)
It really is one meaning: how long should the delay be before an
autosuspend can occur. Setting the delay to 1e9 would be equivalent (for
all practical purposes) to disallowing autosuspend. But instead of
relying on the limiting behavior of very large numbers, it's simpler to
allow negative values into the allowed domain where they can mean exactly
what we want -- no autosuspend.
> > > b) The security implications are different
> >
> > In what way? Why are you so concerned about security implications?
> > Almost all of the writable files in sysfs are writable only by the
> > superuser; this doesn't have to be any different.
>
> Setting a delay shouldn't be limited to root.
>
> > > > I don't understand your point. Preventing a device from autosuspending
> > > > isn't a denial-of-service, although it might be a
> > > > denial-of-power-savings.
> > >
> > > _Allowing_ it is, as we have buggy devices which crash.
> >
> > Yes. That's what PAM is for, right?
>
> Operating on files.
I still don't understand your point of view. You want ordinary users (no
special permissions at all?) to be able to set the autosuspend delay.
Even possibly setting it to such a large value that autosuspend will never
occur (denial of power-savings attack). You perhaps also want ordinary
users to be able to turn autosuspend off entirely. But you definitely
want to require superuser permission to turn autosuspend back on once it
is off.
Is your main concern about the user enabling autosuspend after a kernel
blacklist entry has said that it should remain off? That can be handled
easily enough; the blacklist implementation can be done the way you set
it up originally, so that the device is marked permanently in-use.
Remember, autosuspend is supposed to be an optimization. It's supposed to
be safe. It will trade off power usage for latency, but it shouldn't
cause any errors.
> > > > > Thus a sequence of
> > > > > a) read old delay
> > > > > b) request 0 delay
> > > > > c) restore old delay
> > > > >
> > > > > should suspend the device if it is not doing IO.
> > > >
> > > > Yes, except that both you and Greg have requested that step c) should
> > > > wake up the device and restart the timer using the reinstated old
> > > > delay.
> > > > Of course, if you stop after step b) the effect will be to suspend the
> > > > device as soon as it is no longer in use.
> > >
> > > I am complicated. I have conditional wishes.
> > > I want step (c) to wake up the device only if on/off is included in that
> > > value.
> > > I can't speak for Greg, though.
> >
> > Now you're asking to have two values included in a single sysfs write
> > (on/off and delay). That's a no-no. :-)
>
> Two files, two values, one in each.
To put it more explicitly, you want a change of the delay to wake up the
device only when the on/off switch is on (autosuspend enabled).
However if the on/off switch is off, then a) - c) won't do anything at
all. If the on/off switch is on, then step c) will leave the device
awake, just as it was before. So again, this doesn't make sense.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
