Re: [PATCH 4/4] USB: export autosuspend delay in sysfs

On Mon, 26 Feb 2007, Oliver Neukum wrote:

> If you want to specify it in milliseconds, I have no objections. Other times
> are also given in those units.

Seconds are easier, except in this one case where you want a value less 
than 1 second.  I'm inclined not to worry about it and keep things 
simple.

> > 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)

Be careful in your choice of words.  Do you mean "suspended" or
"autosuspended"?  The kernel basically has no choice about whether a
device should be allowed to suspend.  It _must_ be allowed; otherwise
swsusp won't work.

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.

> 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.

> > 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?

> > > 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.  :-)


> > By now I'm no longer sure what you're asking for.  :-)
> 
> - separate on/off switch

What good is a separate switch?  What's wrong with combining it along with
the delay?

> - allow 0 delay

Okay.

> - 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.

> > 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.

> > 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?

>  If you want such an interface I'd suggest that it mean
> that a device stay suspended until the user says so.

No.  One more time:

		WE ALWAYS WAKE 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!

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel