On Thu, 1 Mar 2007, Oliver Neukum wrote: > Am Mittwoch, 28. Februar 2007 19:44 schrieb Alan Stern: > > > As David mentioned, there are also other reasons for getting rid of > > power/state. > > Then I suggest that we go through to make sure we don't repeat them.
As I recall, none of them (or almost none) applied to USB. Dave probably has more complete memories, though. (Actually I've kind of been hoping that Dave, Greg, or other people on the mailing list would contribute more ideas to this discussion...) > It is not so simple. We are not making a simple interface to control a > device's power state. The power state can change due to other factors, > autosuspend, remote wakeup and demand for IO. Complicated by dealing > with devices and interfaces. Well, we already have an interface to control remote wakeup, and obviously we're not trying to control demand for I/O. I'll settle for controlling the device's power state, including autosuspend as a subset. Get that right and the interfaces will follow. > There is no uniform user space. IO requests originate from different users > and sometimes the kernel itself. You cannot assume that the priviledge to do > IO with a device at the time open() (or equivalent) was called means that > this priviledge remains. Oh dear! This means the entire kernel will have to be rewritten! :-) Seriously, exactly that assumption _is_ made throughout the kernel. That's why open() checks user privileges but read() and write() don't -- they only check whether the fd is open for reading or for writing. > > 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.) > > Yes. > > > Setting the delay to 0 is almost equivalent to asking for an immediate > > suspend. The difference arises only when an interface driver requires > > or there's ongoing IO. That difference is minimal. If there's ongoing I/O then setting the delay to 0 won't have any immediate effect. On the other hand doing an immediate suspend won't have much effect either, because the ongoing I/O will quickly cause an autoresume. > > 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. > > I am afraid not. This introduces a race condition. If a device is woken up > for a specific purpose, the better interface would be an interface that > made the device stay awake until that purpose is satisfied, however long > that may take. I can't think of any way to express the idea of "a specific purpose" in a form the kernel can understand. However the user could always disable autosuspend; that also should force an immediate resume and it wouldn't have any races. (But it might lead to problems if the user then didn't have permission to re-enable autosuspend -- a perverse situation.) > > 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. > > Yes, otherwise the kernel imposes that this priviledge cannot be split. Well, we could do a privilege check in the attribute's store() method. But it would be a lot more flexible to have distinct attributes. > > 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. > > Why not? Take a look at the definition of pm_message_t and tell me where you think the information could be stored. 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
