> > > > 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
-
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]
