Am Dienstag, 27. Februar 2007 19:47 schrieb Alan Stern:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> > 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.
But it allows a driver to specify when it needs those guarantees.
> 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.
So maybe we should export the supported values and keep the interface.
It seems to me that we keep discussing power management and never
come to a solution.
> And the fact remains even though power/state is deprecated, its code
> paths are old, not new.
But they never worked very well.
[..]
> > 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?
That's true.
[..]
> > 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.
But it is reversed as soon as the driver feels like autoresuming.
Either you give the user a way to control power state as he likes it,
or you say that if IO is requested the device must be woken. In the
latter case autosuspend is cool and what you want.
> 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.
Oh, very well. It is not that important. Using a negative value will of course
work. I don't like it, but it works.
> > 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.
Saving power always needs all users' cooperation. A user can always run
silly computations, do strange disk writes, etc... . That's unavoidable.
Therefore I care only about actions that allow one user to make unavailable
devices to other users. As suspending devices can crash some devices,
I consider it one of these activities.
Yes, ST[R|D] will crash those devices, but this needs special permissions,
too.
> 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.
Exactly.
> > > 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).
No, if you have a separate switch, I am fine with a file for delay which
just affects delay, no waking up.
Regards
Oliver
-------------------------------------------------------------------------
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
