Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for2.6.23-rc1)

[Linus Torvalds]

On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
> 
> My point is we have ACPI dependent on PM, so if you want ACPI, you end
> up with all of the STR stuff built in, which is what you don't like (if I
> understand that correctly).  If we have CONFIG_SUSPEND, you'll be able to
> choose ACPI alone. :-)

Good point. 

Anyway, I think the ACPI problem really is as trivial as the following 
three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't 
force it on him.

A nicer fix might be to also make some of the ACPI helper routines depend 
on whether they are needed or not (which in turn will depend on whether 
suspend support has been compiled into the kernel), but quite frankly, 
that's secondary at least for me.

So if we have a few ACPI routines that will never get called (because we 
don't even enable the interfaces that would *cause* them to be called), I 
don't think that's a huge problem. It's a beauty wart, but nobody really 
cares (and it's even something that we could get the compiler to optimize 
away for us if we really cared).

		Linus

---
    Don't force-enable suspend/hibernate support just for ACPI
    
    It's a totally independent decision for the user whether he wants
    suspend and/or hibernation support, and ACPI shouldn't care.
    
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
---
 drivers/acpi/Kconfig |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 251344c..22b401b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -11,9 +11,6 @@ menuconfig ACPI
 	depends on PCI
 	depends on PM
 	select PNP
-	# for sleep
-	select HOTPLUG_CPU if X86 && SMP
-	select SUSPEND_SMP if X86 && SMP
 	default y
 	---help---
 	  Advanced Configuration and Power Interface (ACPI) support for 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/