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
