On Tue, 2005-06-28 at 09:49 +1000, Benjamin Herrenschmidt wrote: > > Let's discuss how we would change the existing PM code... > > > > I was thinking each arch could provide a table of system power states > > with an ->enter() function for each. We would then show the names of > > these states in "/sys/power/state", and the user could select one. Did > > you have something else in mind? > > Yes, that's what Patrick suggested too and I agree. Ok, It's easy enough as far as suspend to RAM is concerned. suspend-to-disk is another matter. I'm not sure what to do with the current crap in there, like the 4 different "methods" etc... that pretty much all assume that the code in kernel/power/disk.c is "in charge" of the whole process (and it's all pretty bogus too, like it doesn't deal with sysdev's). I'm inclined to just trash all of that... but Nigel will have the same problem here, if I start moving the core of swsusp to arch code, he'll have to move the core of swsusp2 accordingly. Also, remains the question then what to do of the resume function. Keep it there or move it in arch code too... We may want to move it to arch code too or we'll end up adding hooks to it... I'm inclined to move everything to arch code, _and_ provide a kind of "default" implementation of suspend-to-disk that you can enable with a CONFIG option that provides an enter() callback that you can drop in your arch it to use "as is" if you don't need any specific callback. However, PM_DISK_PLATFORM and PM_DISK_FIRMWARE sort-of abuse the pm_ops that I have killed to call into arch code... it's all crap as it exposes to all archs some behaviours that may not be supported by those archs. I'm inclined to just ignore it all and simply kill disk.c and let archs re-implement what they want, but I'm sure some people will scream if I do that... Ben.