Hi! > > > And we also need to be able to handle devices in the device tree that do > > > not have a suspend/resume function, or ones that are not attached to any > > > bus, without failing the suspend, as obviously they do not care or need > > > to worry about the whole issue. > > > > 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... 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. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
