Am Montag, 26. Februar 2007 17:03 schrieb Alan Stern:
> On Mon, 26 Feb 2007, Oliver Neukum wrote:
> 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.
If you want to specify it in milliseconds, I have no objections. Other times
are also given in those units.
> 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.
a) The kernel will (or rather should) export its oppinion whether a device
should be suspended (eg. from the blacklist or set by a driver)
b) The security implications are different
> > 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.
_Allowing_ it is, as we have buggy devices which crash.
> > 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 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.
> By now I'm no longer sure what you're asking for. :-)
- separate on/off switch
- allow 0 delay
- don't do an immediate suspend independent of autosuspend
> 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.
> 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. If you want such an interface I'd suggest that it mean
that a device stay suspended until the user says so.
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
