On Wednesday, 4 July 2007 02:34, Matthew Garrett wrote: > On Tue, Jul 03, 2007 at 06:17:04PM -0600, Robert Hancock wrote: > > Matthew Garrett wrote: > > >Leave the process blocked and defer any i/o until after resume. Why does > > >it need to be any more complicated than that? > > > > It gets complicated when this has to be added and TESTED in EVERY > > driver. The implied contract for drivers previously was that their > > device would not get accessed after it was suspended until it had been > > resumed first. This proposed change violates that. > > No, that's only ever been true for ACPI systems. Sorry, but you're mistaken. Some ARM platforms also use the suspend code in kernel/power and the 52xx powerpc too (BTW, I don't know of any ARM platforms that support suspend and don't use it). > It's never been true elsewhere, and it won't be true for anything > implementing any sort of runtime power management. There are not many drivers in the tree supporting that right now. > > I don't think this sort of handling is something that individual drivers > > should have to deal with (at least not ones that are part of a framework > > like USB, libata, etc.) > > I'd agree there. Driver midlayers (where they exist) are the appropriate > place to handle this. So perhaps we should modify them first and we can drop the freezer? Perhaps we can schedule the freezer removal (from the suspend code path), so that people have the time to rework the driver midlayers to take that into account? Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
