[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    Re: [linux-usb-devel] [PATCH 4/4] USB: export autosuspend delay in
From:       Alan Stern <stern () rowland ! harvard ! edu>
Date:       2007-02-28 18:44:34
Message-ID: Pine.LNX.4.44L0.0702281247570.15993-100000 () iolanthe ! rowland ! org
[Download RAW message or body]

On Wed, 28 Feb 2007, Oliver Neukum wrote:

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

As David mentioned, there are also other reasons for getting rid of 
power/state.

We never came to a solution partly because people have all sorts of
varying requirements.  With USB at least the problem is relatively simple:
Devices are either on or suspended.  Hopefully we can figure out a useful
API.


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

I/O requests arise from two sources: the device itself (remote wakeup) or 
userspace.  I agree, we need to give people the ability to suspend devices 
with remote wakeup disabled.  But it doesn't make sense to say that we 
shouldn't autoresume when an I/O request arrives from userspace -- in 
effect, such I/O _is_ a request from the user to turn the device back on.


> No, sorry for being unclear.
> Autosuspend should be coupled with autoresume. The question was about
> an interface which allows user space to do a suspend right now, independent
> of autosuspend.
> Firstly, I don't see a big need for this, so I doubt it's worth the effort.
> Secondly, I see no logic in coupling autoresume with a non-auto suspend.
> It seems to me that if we are to have an interface for suspending without
> the driver requesting/allowing suspension, it would be more usefull if the
> device stayed suspend. Otherwise the difference to autosuspend without
> delay is very small.

Let's try to step back and see the big picture.  And while you think about 
this, consider it not just from the point of view of the kernel or the 
user -- think about what would be most useful to some sort of power 
management daemon.

Clearly we want the user to be able to specify an overall autosuspend 
delay.  (You have even asked to have separate delays for individual 
interfaces.)

Setting the delay to 0 is almost equivalent to asking for an immediate
suspend.  The difference arises only when an interface driver requires
remote-wakeup capability and the user has disabled it (or the device
doesn't support it).  There also has to be a convenient way for the user
to force a suspended device to wake up; setting the delay to something
larger than 0 would be good enough.

We need a way to prevent & allow autosuspend for a device.  Prevention can
be accomplished in a less-than-elegant way by setting the delay to a
negative value, although perhaps we could parse the word "never" or "off".  
The permissions requirements, both for this and for the delay, aren't
entirely clear.  (Most sysfs attributes are writable only by root,
anyway.)  If the two operations require different permissions, then
they probably shouldn't be controlled by the same sysfs attribute.

Open question: Do we need a suspend mode in which the device _doesn't_ 
wake up on request?  I don't think so... and in any case, there's no way 
to pass this information (whether to ignore I/O requests) to the driver.

Recently, power/state has left around mainly for debugging and testing.  
The new API should support that as well.  I'm not sure we would need 
anything in addition to the functions described above.

So this seems to leave us with just two unresolved issues: (1) how to
suspend a device with remote wakeup disabled, and (2) how best to expose
the API in sysfs.  In general people shouldn't have to worry about
suspending their devices and we shouldn't try to create lots of attribute
files.  Indeed, two seems like too many, given that the "wakeup" attribute
already exists.

I'm open to further suggestions...

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
[prev in list] [next in list] [prev in thread] [next in thread]