On Fri 2007-08-03 15:23:19, Len Brown wrote:

On Tuesday 31 July 2007 02:38, Pavel Machek wrote:

quoted

Hi!

quoted

Without this change, it is possible to build CONFIG_HIBERNATE
on all !SMP architectures, but not necessarily their SMP versions.

Did you want to say "CONFIG_SUSPEND"?

Yes.

quoted

quoted

I don't know for sure if the architecture list under SUSPEND_UP_POSSIBLE
is correct.  For now it simply matches the list for
SUSPEND_SMP_POSSIBLE.

I do not think it is.

quoted

Signed-off-by: Len Brown <redacted>
---
 Kconfig |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 412859f..ccf6576 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig

@@ -72,6 +72,11 @@ config PM_TRACE
 	CAUTION: this option will cause your machine's real-time clock to be
 	set to an invalid time after a resume.
 
+config SUSPEND_UP_POSSIBLE
+	bool
+	depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES ||

At least ARM can do suspend, too... probably others. I was under
impression that SUSPEND is "supported" by all the architectures, just
some of them veto it at runtime (using pm_ops or how was it renamed).

The reason this entire thread started is because Linus, Jeff and others
said that they didn't want code magically compiled into their kernel
that they did not explicitly ask for -- even if the savings were small
and that kernel was already something rather beefy, such as ACPI+SMP.

The current code is simply broken, because it allows SUSPEND
on IA64 if UP, but not on SMP.  It should really be neither.

Actually, it should be both, AFAICT. Suspend infrastructure should be
there, just returing -EINVAL... that's how it worked in 2.6.22 IIRC.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html