On Thu, 29 Dec 2005, Dmitry Torokhov wrote: > > There are three obvious possible choices: > > > > 1. open() of a suspended device fails; > > > > 2. open() of a suspended device succeeds but actual input operations > > fail or block; > > > > 3. open() of a suspended device automatically resumes the device. > > > > 1 doesn't sound right. If the device is already open, you don't fail a > > suspend call. So why should you fail an open call just because the device > > is suspended? If you really do want the effect of 1, the correct way to > > do it is to unbind the driver from the device. > > > > Both 2 and 3 are workable. At the moment I don't have any strong feelings > > as to which is better. It's possible that the locking needed to implement > > 3 will be difficult, but I haven't thought over the matter so I'm not > > sure. > > > > My preference would be 3, especially if USB core itself would resume any > suspeded device for which an URB is submitted. In this case I won't have > to change anything in input drivers ;)
3 sounds good. However the USB core is _not_ going to automatically resume any suspended device for which an URB is submitted. The driver will have to explicitly start the resume. And the infrastructure for such driver-initiated runtime resumes has not yet been written. It will be a little tricky, because it may require (for example) resuming the device's parent hub... Furthermore, the infrastructure will also have to include a mechanism for driver-initiated runtime suspend, when an inactivity timer expires. That will complicate things even more. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
