On Wednesday 07 December 2005 11:19 am, Alan Stern wrote: > Dave: > > We need to settle on a policy for handling USB drivers that don't have > suspend/resume support. The current code in 2.6.15-rc returns 0 for the > interface suspend call but doesn't change the interface's power_state > value. As a result, the suspend call for the device fails, aborting the > entire system sleep transition.
It could return a failure code, not zero. ;) > We could not worry about it and call mark_quiesced for the interface. Or Except ... that it is NOT quiesced. That driver might just go issue an URB right away. Having the infrastructure going about lying about things like that would be error prone... A better option might be to mark the device dead/disconnected. None of the invariants would be broken, and the behavior is one that should already be well tested (on resume). And suspend could still work. > we could unbind the driver, in accord with a FIXME comment (although there > are locking issues). One or the other is necessary before 2.6.15 is > released; otherwise there will be lots of complaints about USB updates > breaking suspend. Yes, my patch for the FIXME thing was DOA because of locking problems. My notes say: ... driver core suspend() calls are made with dev->sem held, which means calls to usb_driver_release_interface() always deadlock when they try to claim the same lock. So I'm afraid that "early" disconnect won't work, and it'll have to be done later (by khubd after resume). - Dave ------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
