On Mon, 26 Feb 2007, Oliver Neukum wrote:
> Am Montag, 26. Februar 2007 03:37 schrieb Alan Stern:
> > On Mon, 26 Feb 2007, Oliver Neukum wrote:
>
> > Next you'll be saying that people will want to specify the delay more
> > precisely than the nearest second...
>
> Am I that predictable? It occured to me, but the process takes so long
> that it makes little sense.
I agree, except for one thing. If the delay is set to 0, we might still
want to use a very short delay. For one thing, queue_delayed_work() with
a zero delay won't do anything until the next context switch -- it won't
call the work routine immediately. Also, given that a suspend/resume
cycle takes around 30 ms, people might want to specify a minimum delay of
several tens of millseconds.
> > > We shouldn't. The clean way to do this is to have a boolean setting.
> >
> > Not so. The collection of possible settings is
> >
> > {autosuspend immediately, autosuspend after 1 second,
> > autosuspend after 2 seconds, ..., autosuspend never}.
>
> Why? What reason is there for destroying the delay although you just
> want to switch of autosuspension for now?
If you have told the kernel you want the device not to autosuspend, there
is no reason for the kernel to remember an autosuspend delay. If you then
want to tell the kernel it's okay for the device to autosuspend again, you
can go ahead and re-specify the delay you want to use. The kernel
shouldn't bother to remember the old delay.
> Consider this. Doing suspend at all or not can be critical to
> functionality. According to the spec it shouldn't be, but it is. Whereas
> we have established that a driver should be ready to deal with
> suspension at any point in time. The delay is not a security question,
> the flag is a potential DoS.
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.
> If we take the delay value as such, that is only to specify a delay, which
> I find logical, if it is not mixed with the master on/off switch, a delay
> of 0 should mean "attempt to suspend now"
>
> 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 cannot see the difference to a "suspend now" trigger, if we resume on
> demand. Resumption on demand does mean that the final decision is in
> the driver. The device can stay suspended only if the driver agrees.
> I see no difference to autosuspend in that regard.
> Sure autosuspend is continous, but apart from that?
>
> In addition, if we do it that way, we don't add a third code path for the
> immediate trigger.
By now I'm no longer sure what you're asking for. :-)
Here's what I have been planning: Allow a value of 0 in power/autosuspend
to mean a very short delay (or no delay at all). Allow a negative value
to mean "don't autosuspend". Whenever the attribute file is written,
resume the device and then begin a new autosuspend sequence using the new
delay value.
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).
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.
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
