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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
