Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
Hi! > > Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL? > > Damn, I started thinking about it, and then forgot about it when > finishing the patch. > > My thoughts were: > Is HOTPLUG_CPU still an experimental feature, or has it become a > well-tested no longer experimental feature now that it's used on > most recent laptops? It is complex :-(. HOTPLUG_CPU is pretty solid for the case how _suspend_ uses it (ie drivers quiescent). It is also known broken for _other_ uses. (There was flamewar about that recently). I'm not sure how to express that in Kconfig language without uglyness... We probably could split HOTPLUG_CPU into HOTPLUG_CPU_SUSPEND_ONLY (not experimental) and HOTPLUG_CPU (enables /sysfs interface)... but I do not think that is good idea. (It would also make suspend debugging a bit harder). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
Hi! Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL? Damn, I started thinking about it, and then forgot about it when finishing the patch. My thoughts were: Is HOTPLUG_CPU still an experimental feature, or has it become a well-tested no longer experimental feature now that it's used on most recent laptops? It is complex :-(. HOTPLUG_CPU is pretty solid for the case how _suspend_ uses it (ie drivers quiescent). It is also known broken for _other_ uses. (There was flamewar about that recently). I'm not sure how to express that in Kconfig language without uglyness... We probably could split HOTPLUG_CPU into HOTPLUG_CPU_SUSPEND_ONLY (not experimental) and HOTPLUG_CPU (enables /sysfs interface)... but I do not think that is good idea. (It would also make suspend debugging a bit harder). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Saturday, 28 July 2007 00:25, Adrian Bunk wrote: > On Thu, Jul 26, 2007 at 01:55:18PM -0700, Linus Torvalds wrote: > > > > > > 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 <[EMAIL PROTECTED]> > > --- > > 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 > > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so > what about something like the patch below? > > This should address a main issue behind Len's patch. > > cu > Adrian > > > <-- snip --> > > > An implementation detail of the suspend code that is not intuitive for > the user is the HOTPLUG_CPU dependency of SOFTWARE_SUSPEND if SMP. > > This patch changes SOFTWARE_SUSPEND if SMP to select HOTPLUG_CPU instead > of depending on it. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > > kernel/power/Kconfig | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) > > --- a/kernel/power/Kconfig > +++ b/kernel/power/Kconfig > @@ -72,9 +72,22 @@ 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_SMP_POSSIBLE > + bool > + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) > + depends on SMP > + default y > + > +config SUSPEND_SMP > + bool > + depends on SUSPEND_SMP_POSSIBLE && SOFTWARE_SUSPEND > + select HOTPLUG_CPU > + default y That should not depend on SOFTWARE_SUSPEND (it's equivalent to HIBERNATION). Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, 2007-07-28 at 00:47 +0200, Stefan Richter wrote: > Adrian Bunk wrote: > > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, > > It's not entirely unintuitive. That option's full name is "Support for > suspend on SMP and hot-pluggable CPUs". > I have to give reason to Len Brown on limit the options else this is much more difficult. Make sense define SUSPEND_SMP without define HOTPLUG_CPU ? or make sense define HOTPLUG_CPU without define SUSPEND_SMP ? Even if both options could make sense, we have to have the code prepare for it, which couldn't be prepared. But it is more easier and more importante focus on major cases which is: "I don't care" and force some configuration and everybody test the same code. Else in ACPI we have many issues to resolve like with this define and without other, which philosophically could be interesting but is not the major case and don't let us focus on stability. Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
Adrian Bunk wrote: > On Sat, Jul 28, 2007 at 12:47:37AM +0200, Stefan Richter wrote: >> Yes, that's the price to pay if you want to select something that in >> turn depends on a number of other things. > > Yes, but a good user interface is worth it. That's right. But a hypothetical other way would be to leave Kconfigs minimal ands put the necessary features into scripts/kconfig. -- Stefan -ENOPATCH Richter -=-=-=== -=== ===-- http://arcgraph.de/sr/ - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
Adrian Bunk wrote: On Sat, Jul 28, 2007 at 12:47:37AM +0200, Stefan Richter wrote: Yes, that's the price to pay if you want to select something that in turn depends on a number of other things. Yes, but a good user interface is worth it. That's right. But a hypothetical other way would be to leave Kconfigs minimal ands put the necessary features into scripts/kconfig. -- Stefan -ENOPATCH Richter -=-=-=== -=== ===-- http://arcgraph.de/sr/ - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, 2007-07-28 at 00:47 +0200, Stefan Richter wrote: Adrian Bunk wrote: The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, It's not entirely unintuitive. That option's full name is Support for suspend on SMP and hot-pluggable CPUs. I have to give reason to Len Brown on limit the options else this is much more difficult. Make sense define SUSPEND_SMP without define HOTPLUG_CPU ? or make sense define HOTPLUG_CPU without define SUSPEND_SMP ? Even if both options could make sense, we have to have the code prepare for it, which couldn't be prepared. But it is more easier and more importante focus on major cases which is: I don't care and force some configuration and everybody test the same code. Else in ACPI we have many issues to resolve like with this define and without other, which philosophically could be interesting but is not the major case and don't let us focus on stability. Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Saturday, 28 July 2007 00:25, Adrian Bunk wrote: On Thu, Jul 26, 2007 at 01:55:18PM -0700, Linus Torvalds wrote: 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 [EMAIL PROTECTED] --- 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 The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so what about something like the patch below? This should address a main issue behind Len's patch. cu Adrian -- snip -- An implementation detail of the suspend code that is not intuitive for the user is the HOTPLUG_CPU dependency of SOFTWARE_SUSPEND if SMP. This patch changes SOFTWARE_SUSPEND if SMP to select HOTPLUG_CPU instead of depending on it. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- kernel/power/Kconfig | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -72,9 +72,22 @@ 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_SMP_POSSIBLE + bool + depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y + +config SUSPEND_SMP + bool + depends on SUSPEND_SMP_POSSIBLE SOFTWARE_SUSPEND + select HOTPLUG_CPU + default y That should not depend on SOFTWARE_SUSPEND (it's equivalent to HIBERNATION). Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, Jul 28, 2007 at 12:47:37AM +0200, Stefan Richter wrote: > Adrian Bunk wrote: > > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, > > It's not entirely unintuitive. That option's full name is "Support for > suspend on SMP and hot-pluggable CPUs". > > Only the place where you find the option is unintuitive, as far as its > first application is concerned. (It lives in the "Processor type and > features" menu which is OK for the 2nd application of this option.) And > the variable name of that option is unintuitive because it covers only > the 2nd application of the option, I suppose for historical reasons. We can figure out ourselves when HOTPLUG_CPU is required, so there's no reason to bother the user with it. > > +config SUSPEND_SMP_POSSIBLE > > + bool > > + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) > > + depends on SMP > > + default y > > + > > +config SUSPEND_SMP > > + bool > > + depends on SUSPEND_SMP_POSSIBLE && SOFTWARE_SUSPEND > > + select HOTPLUG_CPU > > + default y > > Yes, that's the price to pay if you want to select something that in > turn depends on a number of other things. Yes, but a good user interface is worth it. > Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL? Damn, I started thinking about it, and then forgot about it when finishing the patch. My thoughts were: Is HOTPLUG_CPU still an experimental feature, or has it become a well-tested no longer experimental feature now that it's used on most recent laptops? > Stefan Richter cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, 28 Jul 2007, Adrian Bunk wrote: > > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so > what about something like the patch below? Yeah, this looks reasonable. May I suggest another level of indirection, though: > +config SUSPEND_SMP_POSSIBLE > + bool > + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) > + depends on SMP > + default y How about making this a bit more split up, and do it as # SMP suspend is possible on .. config SUSPEND_SMP_POSSIBLE bool depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) default y # UP suspend is possible on .. config SUSPEND_UP_POSSIBLE bool depends on X86 || PPC64_SWSUSP || FRV || PPC32 default y # Can we suspend? config SUSPEND_POSSIBLE bool depends on (SMP && SUSPEND_SMP_POSSIBLE) || (SUSPEND_UP_POSSIBLE && !SMP) default y and then we have just a config SOFTWARE_SUSPEND bool "Software Suspend (Hibernation)" depends on PM && SWAP depends on SUSPEND_POSSIBLE config SUSPEND_SMP bool depends on SOFTWARE_SUSPEND && SMP select HOTPLUG_CPU default y and now each of the config options looks pretty simple and describe one thing. [ For extra bonus points: the SUSPEND_POSSIBLE thing is still pretty complicated, and it might actually be a better idea to make it a per-arch config option, and just make the x86/arch say config SUSPEND_POSSIBLE bool depends on !(X86_VOYAGER && SMP) default y instead: since SUSPEND_POSSIBLE is always true on x86 regardless of SMP or not, just not on X86_VOYAGER. Then, each architecture can have its own private rules for whether that architecture has SUSPEND_POSSIBLE or not, so on ppc, it might look like config SUSPEND_POSSIBLE bool depends on (PPC64 && (PPC_PSERIES || PPC_PMAC)) || PPC_SWSUSP bool y or something, but the point is, now the complexity is a per-architecture thing, so other architectures simply don't have to care any more! ] And the user only ever sees one single question: the one for "SOFTWARE_SUSPEND". All the others would directly flow either from the architecture choice, or from that. Anybody willing to rewrite it that way? Linus - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
Adrian Bunk wrote: > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, It's not entirely unintuitive. That option's full name is "Support for suspend on SMP and hot-pluggable CPUs". Only the place where you find the option is unintuitive, as far as its first application is concerned. (It lives in the "Processor type and features" menu which is OK for the 2nd application of this option.) And the variable name of that option is unintuitive because it covers only the 2nd application of the option, I suppose for historical reasons. > +config SUSPEND_SMP_POSSIBLE > + bool > + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) > + depends on SMP > + default y > + > +config SUSPEND_SMP > + bool > + depends on SUSPEND_SMP_POSSIBLE && SOFTWARE_SUSPEND > + select HOTPLUG_CPU > + default y Yes, that's the price to pay if you want to select something that in turn depends on a number of other things. Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL? -- Stefan Richter -=-=-=== -=== ===-- http://arcgraph.de/sr/ - 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/
[2.6 patch] let SUSPEND select HOTPLUG_CPU
On Thu, Jul 26, 2007 at 01:55:18PM -0700, Linus Torvalds wrote: > > > 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 <[EMAIL PROTECTED]> > --- > 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 The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so what about something like the patch below? This should address a main issue behind Len's patch. cu Adrian <-- snip --> An implementation detail of the suspend code that is not intuitive for the user is the HOTPLUG_CPU dependency of SOFTWARE_SUSPEND if SMP. This patch changes SOFTWARE_SUSPEND if SMP to select HOTPLUG_CPU instead of depending on it. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- kernel/power/Kconfig | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -72,9 +72,22 @@ 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_SMP_POSSIBLE + bool + depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y + +config SUSPEND_SMP + bool + depends on SUSPEND_SMP_POSSIBLE && SOFTWARE_SUSPEND + select HOTPLUG_CPU + default y + config SOFTWARE_SUSPEND bool "Software Suspend (Hibernation)" - depends on PM && SWAP && (((X86 || PPC64_SWSUSP) && (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) && !SMP)) + depends on PM && SWAP + depends on ((X86 || PPC64_SWSUSP || FRV || PPC32) && !SMP) || SUSPEND_SMP_POSSIBLE ---help--- Enable the suspend to disk (STD) functionality, which is usually called "hibernation" in user interfaces. STD checkpoints the @@ -132,11 +145,6 @@ config PM_STD_PARTITION suspended image to. It will simply pick the first available swap device. -config SUSPEND_SMP - bool - depends on HOTPLUG_CPU && (X86 || PPC64) && PM - default y - config APM_EMULATION tristate "Advanced Power Management Emulation" depends on PM && SYS_SUPPORTS_APM_EMULATION - 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/
[2.6 patch] let SUSPEND select HOTPLUG_CPU
On Thu, Jul 26, 2007 at 01:55:18PM -0700, Linus Torvalds wrote: 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 [EMAIL PROTECTED] --- 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 The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so what about something like the patch below? This should address a main issue behind Len's patch. cu Adrian -- snip -- An implementation detail of the suspend code that is not intuitive for the user is the HOTPLUG_CPU dependency of SOFTWARE_SUSPEND if SMP. This patch changes SOFTWARE_SUSPEND if SMP to select HOTPLUG_CPU instead of depending on it. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- kernel/power/Kconfig | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -72,9 +72,22 @@ 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_SMP_POSSIBLE + bool + depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y + +config SUSPEND_SMP + bool + depends on SUSPEND_SMP_POSSIBLE SOFTWARE_SUSPEND + select HOTPLUG_CPU + default y + config SOFTWARE_SUSPEND bool Software Suspend (Hibernation) - depends on PM SWAP (((X86 || PPC64_SWSUSP) (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) !SMP)) + depends on PM SWAP + depends on ((X86 || PPC64_SWSUSP || FRV || PPC32) !SMP) || SUSPEND_SMP_POSSIBLE ---help--- Enable the suspend to disk (STD) functionality, which is usually called hibernation in user interfaces. STD checkpoints the @@ -132,11 +145,6 @@ config PM_STD_PARTITION suspended image to. It will simply pick the first available swap device. -config SUSPEND_SMP - bool - depends on HOTPLUG_CPU (X86 || PPC64) PM - default y - config APM_EMULATION tristate Advanced Power Management Emulation depends on PM SYS_SUPPORTS_APM_EMULATION - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
Adrian Bunk wrote: The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, It's not entirely unintuitive. That option's full name is Support for suspend on SMP and hot-pluggable CPUs. Only the place where you find the option is unintuitive, as far as its first application is concerned. (It lives in the Processor type and features menu which is OK for the 2nd application of this option.) And the variable name of that option is unintuitive because it covers only the 2nd application of the option, I suppose for historical reasons. +config SUSPEND_SMP_POSSIBLE + bool + depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y + +config SUSPEND_SMP + bool + depends on SUSPEND_SMP_POSSIBLE SOFTWARE_SUSPEND + select HOTPLUG_CPU + default y Yes, that's the price to pay if you want to select something that in turn depends on a number of other things. Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL? -- Stefan Richter -=-=-=== -=== ===-- http://arcgraph.de/sr/ - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, 28 Jul 2007, Adrian Bunk wrote: The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, so what about something like the patch below? Yeah, this looks reasonable. May I suggest another level of indirection, though: +config SUSPEND_SMP_POSSIBLE + bool + depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y How about making this a bit more split up, and do it as # SMP suspend is possible on .. config SUSPEND_SMP_POSSIBLE bool depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) default y # UP suspend is possible on .. config SUSPEND_UP_POSSIBLE bool depends on X86 || PPC64_SWSUSP || FRV || PPC32 default y # Can we suspend? config SUSPEND_POSSIBLE bool depends on (SMP SUSPEND_SMP_POSSIBLE) || (SUSPEND_UP_POSSIBLE !SMP) default y and then we have just a config SOFTWARE_SUSPEND bool Software Suspend (Hibernation) depends on PM SWAP depends on SUSPEND_POSSIBLE config SUSPEND_SMP bool depends on SOFTWARE_SUSPEND SMP select HOTPLUG_CPU default y and now each of the config options looks pretty simple and describe one thing. [ For extra bonus points: the SUSPEND_POSSIBLE thing is still pretty complicated, and it might actually be a better idea to make it a per-arch config option, and just make the x86/arch say config SUSPEND_POSSIBLE bool depends on !(X86_VOYAGER SMP) default y instead: since SUSPEND_POSSIBLE is always true on x86 regardless of SMP or not, just not on X86_VOYAGER. Then, each architecture can have its own private rules for whether that architecture has SUSPEND_POSSIBLE or not, so on ppc, it might look like config SUSPEND_POSSIBLE bool depends on (PPC64 (PPC_PSERIES || PPC_PMAC)) || PPC_SWSUSP bool y or something, but the point is, now the complexity is a per-architecture thing, so other architectures simply don't have to care any more! ] And the user only ever sees one single question: the one for SOFTWARE_SUSPEND. All the others would directly flow either from the architecture choice, or from that. Anybody willing to rewrite it that way? Linus - 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/
Re: [2.6 patch] let SUSPEND select HOTPLUG_CPU
On Sat, Jul 28, 2007 at 12:47:37AM +0200, Stefan Richter wrote: Adrian Bunk wrote: The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, It's not entirely unintuitive. That option's full name is Support for suspend on SMP and hot-pluggable CPUs. Only the place where you find the option is unintuitive, as far as its first application is concerned. (It lives in the Processor type and features menu which is OK for the 2nd application of this option.) And the variable name of that option is unintuitive because it covers only the 2nd application of the option, I suppose for historical reasons. We can figure out ourselves when HOTPLUG_CPU is required, so there's no reason to bother the user with it. +config SUSPEND_SMP_POSSIBLE + bool + depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y + +config SUSPEND_SMP + bool + depends on SUSPEND_SMP_POSSIBLE SOFTWARE_SUSPEND + select HOTPLUG_CPU + default y Yes, that's the price to pay if you want to select something that in turn depends on a number of other things. Yes, but a good user interface is worth it. Wait, doesn't HOTPLUG_CPU also depend on EXPERIMENTAL? Damn, I started thinking about it, and then forgot about it when finishing the patch. My thoughts were: Is HOTPLUG_CPU still an experimental feature, or has it become a well-tested no longer experimental feature now that it's used on most recent laptops? Stefan Richter cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
