> > > > And we also need to be able to handle devices in the device tree that do > > > > not have a suspend/resume function ... > > > > > > Ah, there's the rub. If a driver doesn't have suspend/resume methods, is > > > it because it doesn't need them, or is it because nobody has written them > > > yet? In the latter case, failing the suspend or unbinding the driver are > > > the only safe courses. > > > > No, if it's not there, just expect that it knows what it is doing, and > > don't fail the thing. Unless you want to add those methods to _every_ > > driver in the kernel, and that's going to be a lot of work...
It seems reasonable to me to require that drivers have at least stub "it's actually OK to do nothing here" suspend/resume methods. > I believe 90% of drivers need them, anyway... Idea is that if we > refuse the suspend, user has dmesg and did not loose his work. If we > suspend but can't resume due to driver problems, it is slightly more > interesting to debug, and user lost open applications. Or as I put it earlier, a clean failure right at the "suspend/resume method missing" point is more robust than unpredictable failures much later (long after that actual failure points). - Dave Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel