Hi Linus,
please pull from: 
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
Fixes regressions -- a build failure, an oops, some dmesg spam.

Also fixes some D-state issues and adds ACPI module auto-loading.

Yes, I'd hoped to get the last two in before rc1.

I'm hopeful that a couple-days into rc2 is sufficiently early for them.
This will update the files shown below.
thanks!
-Len
ps. individual patches are available on linux-acpi@vger.kernel.org

and a consolidated plain patch is available here:

ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2...
 arch/i386/kernel/acpi/Makefile      |    2

 arch/i386/kernel/setup.c            |    2

 arch/i386/mm/init.c                 |    2

 arch/ia64/kernel/acpi.c             |   19 ++

 arch/x86_64/kernel/acpi/Makefile    |    2

 arch/x86_64/kernel/acpi/sleep.c     |    4

 arch/x86_64/kernel/head.S           |    2

 arch/x86_64/kernel/setup.c          |    2

 drivers/acpi/Kconfig                |   64 +++------

 drivers/acpi/ac.c                   |    9 +

 drivers/acpi/acpi_memhotplug.c      |    8 +

 drivers/acpi/asus_acpi.c            |   11 +

 drivers/acpi/battery.c              |    9 +

 drivers/acpi/button.c               |   12 +

 drivers/acpi/container.c            |   10 +

 drivers/acpi/ec.c                   |    8 -

 drivers/acpi/events/evrgnini.c      |    2

 drivers/acpi/fan.c                  |    8 +

 drivers/acpi/namespace/nsxfeval.c   |    2

 drivers/acpi/pci_link.c             |    9 +

 drivers/acpi/pci_root.c             |    9 +

 drivers/acpi/power.c                |    8 +

 drivers/acpi/processor_core.c       |    8 +

 drivers/acpi/processor_throttling.c |   59 ++++++--

 drivers/acpi/sbs.c                  |   10 +

 drivers/acpi/scan.c                 |  156 ++++++++++++++++-------

 drivers/acpi/sleep/Makefile         |    4

 drivers/acpi/sleep/main.c           |  162 +++++++++++++++++++-----

 dri...
[ message continues ]

I hate pulling this, but I did. However, what I hate even more after

having done so is that ACPI now seems to select CPU hotplug. Why?
That is just *broken*. Sure, if you select STR or hibernation, we need CPU

hotplug, but just for picking ACPI? Why?
		Linus

-

ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support,

and that requires HOTPLUG_CPU=y.
Note that ACPI=y SMP=n systems do not need it,
My assumption is that if somebody selects CONFIG_ACPI,

that 99% of the time, they intend that to include support for

the ACPI hooks for system sleep states.
Conversely, supporting the 1% of people who don't want it

isn't worth messing with the 99% who do, nor is

the burden of yet another config option to maintain and

#ifdefs in the code.
On UP, they'd get ACPI system sleep support 100% of the time

by default, but on SMP this option had become problematic.
We used to have this:
if ACPI

...

config ACPI_SLEEP

        bool "Sleep States"

        depends on X86 && (!SMP || SUSPEND_SMP)

        depends on PM

        default y
So the poster-child failure was i386/defconfig itself...

It couldn't support suspend to RAM because it didn't include

CONFIG_ACPI_SLEEP.  Not trivial for a user to select it

when it doesn't even appear on the menu.  It doesn't appear

because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't

appear either -- because CONFIG_HOTPLUG_CPU isn't selected.
Most users don't want that.
So today we have this:
menuconfig ACPI

	...

        select HOTPLUG_CPU if X86 && SMP

        select SUSPEND_SMP if X86 && SMP
Which I think leads to fewer surprises, and less complicated code.

(even though using select itself is fraught with peril:-)
thanks,

-Len
-

so you are saying that you know better then we do what we need?
some people configure ACPI only becouse their system won't work properly

without it. they have no intention of ever doing a STR or hibernate.
so have something like
config ACPI_SLEEP

         select HOTPLUG_CPU if X86 && SMP

         select SUSPEND_SMP if X86 && SMP
instead of makeing it dependant on ACPI.
-

Feel free to share what you know about the benefits vs. the costs
I agree.
Further, I expect that 100% - (some people %) = 99%
If you feel that your system has been degraded

because it now includes what used to be excluded under
If more config options where better, then this

would indeed be an improvement over 2.6.22.

But more config options isn't better -- except for "some people":-)
thanks.

-

coupling unrelated fetures togeather isn't better either.
David Lang

-

Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND 
I feel that I get asked to include a feature that

 (a) I have no interest in on that machine

 (b) I didn't need to include before.
What was the advantage? And what was it that caused something like this to

be a post-rc1 thing. That makes me really unhappy. This is a *regression*.
		Linus

-

CONFIG_STR doesn't exist.
I agree it is an attractive notion to have a high level feature presented

to the user, and that the tools should select what is needed to satisfy the

user's request.  Unfortunately Kconfig is exceptionally bad at supporting

this model.  "depend" frustrates users by making config options vanish

without explanation, and "select" is fundamentally broken
I'm sorry that one fewer config options has offended your feeling of freedom,

honestly, I am.
I was actually asking how somebody's _system_ has been degraded

by this change -- but I haven't got an objective answer to that one yet.
As I said in my pull request, I agree that the D-state fixes ideally

should have merged a week earlier -- before the rc1 cutoff.

Indeed, we had a hack that could have gone up much earlier.

However, we waited for Rafael's more general list-blessed solution --

and it turned out that solution tripped over CONFIG_ACPI_SLEEP=n.
The reason is because there is a dependency between D-states and S-states.

In particular, devices which are enabled to be system wakeup devices

can be limited in what D-states they can enter (else they may

no longer be able to wake up the system when it is suspended)
I figured that rather than adding more ifdefs to solve that problem,

it was simpler to remove ifdefs.  I was also shocked to find i386 defconfig

with CONFIG_ACPI_SLEEP=n.  Maybe others are not shocked by this

and there is a reason that defconfig on x86_64 supports sleep

and i386 does not.  I assumed it was a bug, maybe I was wrong.
The context for this is the EPA ENERGY STAR specification for Computers,

which went into effect this month.  This spec says that systems which

can not automatically go into suspend within 15 minutes of idle

can _not_ earn a sticker.  No sticker, no client computer sales to governments.

If Linux can't get STR working, broadly deployed, and enabled by default,

then our plans for world domination are going to take a significant hit.
yes, I understand that there ...
[ message continues ]

how about the fact that Linus found the problem becouse his system didn't 
isn't the sticker and specification for hardware? but in any case not all 
the idea is that code that doesn't get compiled into the kernel can't

cause the system to misbehave.
David Lang

-

No, it works, it just forces me to use a configuration that I'm not

personally interested in on that particular machine.
I tend to like using minimal kernels. I don't use modules on most of my

machines, and I actually look over my config. Maybe I'm odd. But I think

it's a good thing to let people decide what they want (and what they do

_not_ want) in their kernels.
I think forcing people to use CPU_HOTPLUG is a mistake. There's a reason

that existed as a config option. The ACPI changes basically mean that the

whole CPU_HOTPLUG config option is totally pointless, because everybody is

forced to have it.
		Linus

-

Indeed -- forced to have a feature that is applicable in reality to

0.00000001% of the user population, I'd wager :)
I read and hone my .config to utter minimalist perfection too :)  So

count my vote here too, for -not- wanting CPU_HOTPLUG dead code in my

kernel.
	Jeff
-

I guess I missed that message.  What system didn't work right,
No, the sticker is for the entire system (HW+SW) as shipped to the customer.

ie. It is possible for the same hardware solution running Windows

to earn a sticker and land a sale, while Linux fails to earn a sticker

and loses the contract.
You're right, not all systems need to earn the sticker.

Indeed, ENERGY STAR is supposed to be a "premium" brand.

However, several governments disqualify bids for large
Apparently a market for more config options of is alive and well.

Thank you for helping make the future of Linux more clear to me.
-Len

-

According to that logic, we should always compile *everything* in.
Do you see the problem?
And can you realize that this should not have happened after -rc1?
So send me the patch to undo this breakage, and stop making excuses.
		Linus

-

Hmm, perhaps we should introduce a CONFIG_SUSPEND and change

CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on

CONFIG_PM?
There's quite some code needed only for suspend compiled in when CONFIG_PM is

set ...
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

Sounds like a good idea, although I suspect that CONFIG_PM really *is*

fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is

largely useless without at least STR.
(Yes, I realize that you can do per-driver suspend events etc, but I

suspect not a lot of people have used it).
But from a logical standpoint, it does make sense to have a separate

config option for the STR support.
		Linus

-

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
Exactly.
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

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@linux-foundation.org>

---

 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

-

That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume.

While cpu0 is in a known state when the power goes out,

without HOTPLUG_CPU the other cpus (and the memory they touch)

are in an indeterminate state.
Yes, we could invent a new mechanism to offline the other CPUS

before suspend and online them upon resume,

but that is what the more general HOTPLUG_CPU code does for us already.

Indeed, that is pretty much _all_ that HOTPLUG_CPU code does on X86 --

as we don't have any physical hotplug support today beneath
Re: warts, I agree.

My question is why the HOTPLUG_CPU=y code is any different.

When I compile HOTPLUG_CPU out of an x86_64 kernel, the kernel shrinks

by only 18KB, which on a kernel that has ACPI+SMP doesn't seem

like such a big wart.
Yes, now that you brought it up, I think it would be just dandy if

HOTPLUG_CPU simply got folded into SMP -- for I see little to no benefit

to having it as its own config option.
But on the assumption that you are not swayed (when was the last time you were?)

and you still feel strongly we should be able to exclude ACPI_SLEEP and HOTPLUG_CPU

from ACPI+SMP kernels, I'll send you a patch do to that properly.

It will largely restores things to how we had them in 2.6.22.

It looks like a step backwards to me, but you may see it differently.
-Len

-

Explain that to me.
There should *be* no resume.
ACPI doesn't suspend/resume on its own, I hope.
It is all done by the top-level suspend/resume code, not by ACPI. ACPI is

a pure helper, and if you've changed that, then I think we need to revert

more than a few lines.
And it's the *top*level* code that selects HOTPLUG_CPU. Through

SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND.
This is why it's so *totally* and *utterly* bogus for ACPI to select

features that it has nothign what-so-ever to do with. 
In other words: ACPI isn't in the driving seat. 
			Linus

-

In other words, the problem seems to be that 
	kernel/power/main.c:

		suspend_devices_and_enter()
does the proper "disable/enable_nonboot_cpus()", but it does so without

having enabled CPU hotplug.
And you seem to think that it's ACPI that should enable the hotplug, even

though the code that actually needs it is _outside_ ACPI. And I think

that's wrong, and that this is a bug.
So I think the real issue is that we allow that

"suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in

the first place. It's not supposed to work that way.
Of course, it may well be that other architectures can happily suspend

even with multiple CPU's active, which may be the cause of this mess. But

I really think it shouldn't be ACPI that has to select the CPU hotplug,

since it's not ACPI that _uses_ it in the first place.
Rafael: making a config option for STR (the same way we have a config

option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU

seems to be the right thing. Len is right in that we do insane things

right now (trying to STR with multiple CPU's still active), and I just

don't think he's the one that should work around it!
		Linus

-

I don't see how CONFIG_HOTPLUG_CPU justifies its own existence.

This e-mail thread would have never happened if it were simply included

in CONFIG_SMP, always.
I agree, of course, that ACPI should never have had to work-around

this by selecting HOTPLUG_CPU.  But even though it is now done at

the right layer, I don't see why PM should have to

be bothered with selecting HOTPLUG_CPU either --

it should just come with SMP.
-Len

-

why do you need hotplug just becouse you have muliple cpus? if you never

have any intention of useing suspend and your hardware doesn't support

hotplugging, why should you have to include the code for it?
Dvaid Lang

-

Because otherwise we have way too many config options, and there are

basically no downsides? Too many options => too little testing of each

permutation...

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

Well, I agree and that's why I asked. :-)
OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require

quite a bit of (compilation) testing on different architectures.
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

Sure. I'm not too worried, the fallout should be of the trivial kind. 
Also, mind basing it on the (independent) cleanups that Adrian already

sent out. This is all intertwined..
		Linus

-

OK, it took more time than I had hoped, but I wanted CONFIG_HIBERNATION and

CONFIG_SUSPEND to be really independent of each other.
The two patches in the next messages implement the idea:

* replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION

* introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary,

  and make it possible to choose suspend and hibernation independently of each

  other.
Greetings,

Rafael
-

Unfortunately, the patches that I have posted are against 2.6.23-rc1 with the

suspend and hibernation patchset applied

(http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc1/patches/) .
Sorry for that.
The corresponding patches on top of the current -git are in the next two

messages.
They do the following:

* replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION

* introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary,

  and make it possible to choose suspend and hibernation independently of each

  other

* update the top-level PM-related headers and the ACPI code related to suspend

  and hibernation to use the new definitions
Greetings,

Rafael
-

Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on

top of it (I took the easy way out, and just made PM_SLEEP imply

ACPI_SLEEP, which should make everything come out right. I could have

dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have

implied changing more of Len's patch than I was really comfy with).
Len, Rafael, please do check that the end result looks ok. 
I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into

account, and that some of the code is not necessary when HIBERNATE is not

selected, for example, but I'm not at all sure that it's worth it being

very fine-grained.
		Linus

-

From: Len Brown <len.brown@intel.com>
CONFIG_ACPI_PROCFS_SLEEP is a NO-OP -- delete it (again).
Apparently 296699de6bdc717189a331ab6bbe90e05c94db06 creating CONFIG_SUSPEND

and CONFIG_PM_SLEEP was based on an out-dated version of drivers/acpi/Kconfig,

as it erroneously restored this recently deleted config option.
Signed-off-by: Len Brown <len.brown@intel.com>

---

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig

index 934d639..f1372de 100644

--- a/drivers/acpi/Kconfig

+++ b/drivers/acpi/Kconfig

@@ -68,14 +68,6 @@ config ACPI_PROCFS
 	  Say N to delete /proc/acpi/ files that have moved to /sys/
-config ACPI_PROCFS_SLEEP

-	bool "/proc/acpi/sleep (deprecated)"

-	depends on PM_SLEEP && ACPI_PROCFS

-	default n

-	---help---

-	  Create /proc/acpi/sleep

-	  Deprecated by /sys/power/state

-

 config ACPI_AC

 	tristate "AC Adapter"

 	depends on X86

-

Some chunks of code in drivers/acpi/sleep/proc.c depend on

CONFIG_ACPI_PROCFS_SLEEP.  Do you also intend to remove that code?
Greetings,

Rafael

-

From: Linus Torvalds <torvalds@linux-foundation.org>
Without this change, it is possible to build CONFIG_HIBERNATE

on all !SMP architectures, but not necessarily their SMP versions.
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.
Signed-off-by: Len Brown <len.brown@intel.com>

---

 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 || PPC_PMAC))

+	default y

+

 config SUSPEND_SMP_POSSIBLE

 	bool

 	depends on (X86 && !X86_VOYAGER) || (PPC64 && (PPC_PSERIES || PPC_PMAC))

@@ -92,7 +97,7 @@ config PM_SLEEP

 config SUSPEND

 	bool "Suspend to RAM and standby"

 	depends on PM

-	depends on !SMP || SUSPEND_SMP_POSSIBLE

+	depends on (!SMP && SUSPEND_UP_POSSIBLE) || (SMP && SUSPEND_SMP_POSSIBLE)

 	default y

 	---help---

 	  Allow the system to enter sleep states in which main memory is

-

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).

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

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.
Further, the only requirement to enable CONFIG_SUSPEND by default

is PM && CONFIG_SMP=n, and that doesn't make much sense -- particularly

since many of the non X86 architectures are small and according

to the logic above, if SUSPEND (and PM_SLEEP, which it enables)

adds any code to those kernels when they don't need it,

then it would be a regression.
thus my patch, if there is a list for SMP, there should

be a list for !SMP.  If the list is incomplete, we need to fix it.
-Len
-

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

-

Historically, suspend support was implied by CONFIG_PM.
For now, it's not much point in using CONFIG_PM at all if the arch in question

doesn't support suspending or hibernation, so I thought it would be better to

leave it unrestricted.
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

SUSPEND depends only on (!SMP || SUSPEND_SMP_POSSIBLE).

This means that while we limit the architectures it can build on

if they are SMP, it can build on any !SMP architecture --

which probably isn't what we want.
I think the right way to go is your SUSPEND_UP_POSSIBLE suggestion.

Honestly, I though it was overly verbose when I first read it,

but I like it better now, especially since it works;-)
As you know, I don't think that it is worth dedicated config options

to save 16KB on an SMP+ACPI kernel.  The prospect of adding code to

slice that 16KB into finer grain savings seems even less worthwhile.
-Len

-

I only found two really minor issues covered by the appended patch (on top of
Well, IMO, for now let's make sure everything works as is. :-)
Greetings,

Rafael
---

(1) I think it's better to use CONFIG_ACPI_SLEEP instead of CONFIG_PM_SLEEP in

    include/acpi/acpi_bus.h , too, for consistency.
(2) x86_64 defconfig is outdated
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 arch/x86_64/defconfig   |    3 ---

 include/acpi/acpi_bus.h |    6 +++---

 2 files changed, 3 insertions(+), 6 deletions(-)
Index: linux-2.6/include/acpi/acpi_bus.h

===================================================================

--- linux-2.6.orig/include/acpi/acpi_bus.h	2007-07-30 07:58:48.000000000 +0200

+++ linux-2.6/include/acpi/acpi_bus.h	2007-07-30 08:25:32.000000000 +0200

@@ -366,16 +366,16 @@ acpi_handle acpi_get_child(acpi_handle,

 acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);

 #define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)->archdata.acpi_handle))
-#ifdef CONFIG_PM_SLEEP

+#ifdef CONFIG_ACPI_SLEEP

 int acpi_pm_device_sleep_state(struct device *, int, int *);

-#else /* !CONFIG_PM_SLEEP */

+#else /* !CONFIG_ACPI_SLEEP */

 static inline int acpi_pm_device_sleep_state(struct device *d, int w, int *p)

 {

 	if (p)

 		*p = ACPI_STATE_D0;

 	return ACPI_STATE_D3;

 }

-#endif /* !CONFIG_PM_SLEEP */

+#endif /* !CONFIG_ACPI_SLEEP */
 #endif				/* CONFIG_ACPI */
Index: linux-2.6/arch/x86_64/defconfig

===================================================================

--- linux-2.6.orig/arch/x86_64/defconfig	2007-07-30 07:58:48.000000000 +0200

+++ linux-2.6/arch/x86_64/defconfig	2007-07-30 08:27:27.000000000 +0200

@@ -207,9 +207,6 @@ CONFIG_SUSPEND_SMP=y

 # ACPI (Advanced Configuration and Power Interface) Support

 #

 CONFIG_ACPI=y

-CONFIG_ACPI_SLEEP=y

-CONFIG_ACPI_SLEEP_PROC_FS=y

-CONFIG_ACPI_SLEEP_PROC_SLEEP=y

 CONFIG_ACPI_PROCFS=y

 CONFIG_ACPI_AC=y

 CONFIG_ACPI_BATTERY=y

-

From: Rafael J. Wysocki <rjw@sisk.pl>
Introduce CONFIG_SUSPEND representing the ability to enter system sleep states,

such as the ACPI S3 state, and allow the user to choose SUSPEND and HIBERNATION

independently of each other.
Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has been

chosen and the kernel is intended for SMP systems.
Also, introduce CONFIG_PM_SLEEP which is automatically selected if

CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the code

needed for both suspend and hibernation.
The top-level power management headers and the ACPI code related to suspend and

hibernation are modified to use the new definitions (the changes in

drivers/acpi/sleep/main.c are, mostly, moving code to reduce the number of

ifdefs).  Still, there are many other files in which CONFIG_PM can be replaced

with CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in

the future.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 drivers/acpi/Kconfig        |    8 +++

 drivers/acpi/sleep/Makefile |    2

 drivers/acpi/sleep/main.c   |   94 +++++++++++++++++++++++---------------------

 drivers/acpi/sleep/proc.c   |   10 ++--

 drivers/acpi/sleep/sleep.h  |    2

 drivers/base/power/Makefile |    2

 drivers/base/power/power.h  |    4 -

 include/acpi/acpi_bus.h     |    9 ++++

 include/acpi/acpi_drivers.h |    4 +

 include/linux/freezer.h     |    6 +-

 include/linux/pm.h          |   15 +++++--

 include/linux/suspend.h     |   10 ++--

 kernel/power/Kconfig        |   39 ++++++++++++++----

 kernel/power/Makefile       |    3 -

 kernel/power/main.c         |   26 ++++++++----

 kernel/power/power.h        |   10 ++++

 mm/page_alloc.c             |    4 -

 17 files changed, 163 insertions(+), 85 deletions(-)
Index: linux-2.6/kernel/power/Kconfig

===================================================================

--- linux-2.6.orig/kernel/power/Kconfig	2007-07-29 19:06:26.000000000 +0200

+++ linux-2.6/kernel/power/Kconfig	...
[ message continues ]

There is #ifdef CONFIG_PM

around all the .suspend and .resume methods.
Technically they are PM_DEVICE_STATES or something,

that could really be under PM, and both SUSPEND and HIBERNATE

would depend on PM_DEVICE_STATES, but it is also possible to have

PM_DEVICE_STATES without SUSPEND and HIBERNATE.
oh no, I just suggested more instead of fewer config options:-O
but i agree, this can wait a bit...
-Len

-

Well, the people on linux-pm seem to agree that the .suspend() and .resume()

callbacks are not suitable for runtime power management, so having them

built without SUSPEND or HIBERNATION wouldn't be very useful. ;-)
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

These are what USB runtime power management uses. How many code

paths for power management do you want to introduce?
	Regards

		Oliver

-

To be precise, I think the rule should be that if some code is needed for

anything else than suspend/hibernation, it should be under plain CONFIG_PM.

Still, if something is only needed for suspend/hibernation, it should go under

CONFIG_PM_SLEEP or CONFIG_SUSPEND/HIBERNATION, depending on what it's needed

for.
Now, AFAICS, for the majority of drivers .suspend() and .resume() are only

needed for suspend/hibernation and really should be used for suspending
At least one more, for hibernation.
That also depends on what approach to the runtime power management is widely

accepted.  For now, USB is in the vanguard. :-)
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

From: Rafael J. Wysocki <rjw@sisk.pl>
Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid confusion

(among other things, with CONFIG_SUSPEND introduced in the next patch).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 arch/i386/Kconfig.debug                 |    4 ++--

 arch/i386/kernel/e820.c                 |    2 +-

 arch/i386/mm/init.c                     |    2 +-

 arch/i386/power/Makefile                |    2 +-

 arch/powerpc/Kconfig.debug              |    2 +-

 arch/powerpc/configs/lite5200_defconfig |    2 +-

 arch/powerpc/configs/pmac32_defconfig   |    2 +-

 arch/powerpc/kernel/Makefile            |    6 +++---

 arch/ppc/configs/TQM8540_defconfig      |    2 +-

 arch/ppc/configs/TQM8541_defconfig      |    2 +-

 arch/ppc/configs/TQM8555_defconfig      |    2 +-

 arch/ppc/configs/TQM8560_defconfig      |    2 +-

 arch/ppc/configs/ev64360_defconfig      |    2 +-

 arch/ppc/configs/ml300_defconfig        |    2 +-

 arch/ppc/configs/ml403_defconfig        |    2 +-

 arch/ppc/configs/mpc834x_sys_defconfig  |    2 +-

 arch/ppc/configs/prep_defconfig         |    2 +-

 arch/sparc64/Kconfig.debug              |    2 +-

 arch/x86_64/defconfig                   |    2 +-

 arch/x86_64/kernel/Makefile             |    2 +-

 arch/x86_64/kernel/suspend.c            |    4 ++--

 drivers/acpi/sleep/main.c               |    6 +++---

 drivers/acpi/sleep/proc.c               |    2 +-

 drivers/i2c/chips/tps65010.c            |    2 +-

 include/asm-i386/e820.h                 |    2 +-

 include/linux/suspend.h                 |    8 ++++----

 kernel/power/Kconfig                    |    6 +++---

 kernel/power/Makefile                   |    2 +-

 kernel/power/main.c                     |    2 +-

 kernel/power/power.h                    |    2 +-

 kernel/sys.c                            |    2 +-

 mm/Kconfig                              |    4 ++--

 mm/swapfile.c                           |    6 +++---

 33 files changed, 47 insertions(+), 47 deletio...
[ message continues ]

From: Rafael J. Wysocki <rjw@sisk.pl>
Introduce CONFIG_SUSPEND representing the ability to enter system sleep states,

such as the ACPI S3 state, and allow the user to choose SUSPEND and HIBERNATION

independently of each other.
Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has been

chosen and the kernel is intended for SMP systems.
Also, introduce CONFIG_PM_SLEEP which is automatically selected if

CONFIG_SUSPEND or CONFIG_HIBERNATION is set and make CONFIG_ACPI_SLEEP depend

on it.
The top-level power management headers are modified to use the new definitions.

Still, there are many other files in which CONFIG_PM can be replaced with

CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in the

future.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 drivers/acpi/Kconfig        |    2 +-

 drivers/base/power/Makefile |    6 +++---

 drivers/base/power/power.h  |    4 ++--

 include/acpi/acpi_bus.h     |    7 +++++++

 include/linux/freezer.h     |    6 +++---

 include/linux/pm.h          |    8 ++++----

 include/linux/suspend.h     |   16 ++++++++--------

 kernel/power/Kconfig        |   39 +++++++++++++++++++++++++++++++--------

 kernel/power/Makefile       |    3 ++-

 kernel/power/main.c         |   26 ++++++++++++++++++--------

 kernel/power/power.h        |   10 +++++++++-

 mm/page_alloc.c             |    4 ++--

 12 files changed, 90 insertions(+), 41 deletions(-)
Index: linux-2.6.23-rc1/kernel/power/Kconfig

===================================================================

--- linux-2.6.23-rc1.orig/kernel/power/Kconfig	2007-07-29 11:05:14.000000000 +0200

+++ linux-2.6.23-rc1/kernel/power/Kconfig	2007-07-29 11:18:49.000000000 +0200

@@ -46,7 +46,7 @@ config PM_VERBOSE
 config DISABLE_CONSOLE_SUSPEND

 	bool "Keep console(s) enabled during suspend/resume (DANGEROUS)"

-	depends on PM_DEBUG

+	depends on PM_DEBUG && PM_SLEEP

 	default n

 	---help---

 	This option turns off the console suspend mechanism that ...
[ message continues ]

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
-

Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

Whatever it includes - please tell it to the user in the prompt.
Technical issues are important, but it's often forgotten how many

problems people run into because the description of a kconfig option 
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
-

Sure.  Please see the updated patch I've just sent. :-)
Greetings,

Rafael

-

So are you guys using:
"standby" = idle state, ~0.5 seconds

"suspend" = sleep to ram, ~10 seconds

"hibernate" = sleep to disk, ~30 seconds
If so - you rock. This is the common nomenclature I've been pushing for

a few months now in GNOME, KDE and general userspace. I've written up a

spec here:

http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/sleep-n...
Richard.
-

Well, those times don't quite work for my PowerBook.  If we fixed

suspend-to-RAM to reinitialize devices in parallel then it would

easily hit 0.5 second transition times, but even now it's only at

most 2 seconds.  Also once in a while I'll be too hasty plugging my

USB devices and manage to hardlock one of the USB busses, but that's

an isolated USB driver suspend issue.
And it's certainly not called "standby", because the box can

literally remain asleep for 7 days on a full charge, versus about 5

hours when just idle with wireless, backlight, and HDD off.
Cheers,

Kyle Moffett

-

Something like this, but "suspend" is not reserved as a name of specific state.
The second state is usually referred to as "suspend to RAM" or "STR" and is

denoted by "mem" in /sys/power/state, if implemented.  Moreover, "standby" and

"mem" are both entered using the same code path, so they may generally be

referred to as "suspend" states.
The times aren't strictly defined for "mem" and "standby", too.  The general

rule is that the times for "mem" are greater then for "standby" and the power

drawn in "mem" is smaller than the power drawn in "standby", but the exact

values will always depend on the platform.  Apart from this, if the platform

supports only one "suspend" state, it decides if that's "mem" or "standby".
On ACPI systems "standby" and "mem" correspond to the S1 and S3 sleep states,

respectively.
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

And I'd expect ~2seconds for both "standby" and "mem" on ACPI

system. ACPI S1 is just "for windows ME compatibility, do not use" --

it draws too much power, and is not really faster.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-

From: Rafael J. Wysocki <rjw@sisk.pl>
Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid confusion

(among other things, with CONFIG_SUSPEND introduced in the next patch).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 arch/i386/Kconfig.debug                 |    4 ++--

 arch/i386/kernel/e820.c                 |    2 +-

 arch/i386/mm/init.c                     |    2 +-

 arch/i386/power/Makefile                |    2 +-

 arch/powerpc/Kconfig.debug              |    2 +-

 arch/powerpc/configs/lite5200_defconfig |    2 +-

 arch/powerpc/configs/pmac32_defconfig   |    2 +-

 arch/powerpc/kernel/Makefile            |    6 +++---

 arch/ppc/configs/TQM8540_defconfig      |    2 +-

 arch/ppc/configs/TQM8541_defconfig      |    2 +-

 arch/ppc/configs/TQM8555_defconfig      |    2 +-

 arch/ppc/configs/TQM8560_defconfig      |    2 +-

 arch/ppc/configs/ev64360_defconfig      |    2 +-

 arch/ppc/configs/ml300_defconfig        |    2 +-

 arch/ppc/configs/ml403_defconfig        |    2 +-

 arch/ppc/configs/mpc834x_sys_defconfig  |    2 +-

 arch/ppc/configs/prep_defconfig         |    2 +-

 arch/sparc64/Kconfig.debug              |    2 +-

 arch/x86_64/defconfig                   |    2 +-

 arch/x86_64/kernel/Makefile             |    2 +-

 arch/x86_64/kernel/suspend.c            |    4 ++--

 drivers/acpi/sleep/main.c               |    6 +++---

 drivers/acpi/sleep/proc.c               |    2 +-

 drivers/i2c/chips/tps65010.c            |    2 +-

 include/asm-i386/e820.h                 |    2 +-

 include/linux/suspend.h                 |    8 ++++----

 kernel/power/Kconfig                    |    6 +++---

 kernel/power/Makefile                   |    2 +-

 kernel/power/main.c                     |    2 +-

 kernel/power/power.h                    |    2 +-

 kernel/sys.c                            |    2 +-

 mm/Kconfig                              |    4 ++--

 mm/swapfile.c                           |    6 +++---

 33 files changed, 47 insertions(+), 47 deletio...
[ message continues ]

From: Len Brown <len.brown@intel.com>
Restore the 2.6.22 CONFIG_ACPI_SLEEP build option,

with a few differences:

1. selects HOTPLUG_CPU rather than depends on HOTPLUG_CPU.

2. ACPI_SLEEP can be enabled on IA64
Disabling this option shrinks the kernel by 16KB.
Disabling this option on SMP allows the user to

deselect HOTPLUG_CPU and save an addition 18KB.
Signed-off-by: Len Brown <len.brown@intel.com>

---

 arch/i386/kernel/acpi/Makefile   |    2 +-

 arch/i386/kernel/setup.c         |    2 +-

 arch/x86_64/kernel/acpi/Makefile |    2 +-

 arch/x86_64/kernel/head.S        |    2 +-

 arch/x86_64/kernel/setup.c       |    2 +-

 drivers/acpi/Kconfig             |   17 +++++++++++++++++

 drivers/acpi/sleep/Makefile      |    4 ++--

 drivers/acpi/sleep/poweroff.c    |    2 ++

 drivers/acpi/sleep/proc.c        |    2 +-

 drivers/pci/pci-acpi.c           |    4 ++++

 drivers/pnp/pnpacpi/core.c       |    4 ++++

 include/acpi/acpi_drivers.h      |    4 ++++

 kernel/sysctl.c                  |    2 +-

 13 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/i386/kernel/acpi/Makefile b/arch/i386/kernel/acpi/Makefile

index 223f58f..7f7be01 100644

--- a/arch/i386/kernel/acpi/Makefile

+++ b/arch/i386/kernel/acpi/Makefile

@@ -2,7 +2,7 @@ obj-$(CONFIG_ACPI)		+= boot.o

 ifneq ($(CONFIG_PCI),)

 obj-$(CONFIG_X86_IO_APIC)	+= earlyquirk.o

 endif

-obj-$(CONFIG_ACPI)		+= sleep.o wakeup.o

+obj-$(CONFIG_ACPI_SLEEP)	+= sleep.o wakeup.o
 ifneq ($(CONFIG_ACPI_PROCESSOR),)

 obj-y				+= cstate.o processor.o

diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c

index 7fe5da3..d474cd6 100644

--- a/arch/i386/kernel/setup.c

+++ b/arch/i386/kernel/setup.c

@@ -422,7 +422,7 @@ void __init setup_bootmem_allocator(void)

 	 */

 	reserve_bootmem(PAGE_SIZE, PAGE_SIZE);

 #endif

-#ifdef CONFIG_ACPI

+#ifdef CONFIG_ACPI_SLEEP

 	/*

 	 * Reserve low memory region for sleep support.

 	 */

diff --git a/arch/x86_64/kernel/acpi/Makefile b/arch/x86_64/kernel/acpi/Makefile

...
[ message continues ]

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 <bunk@stusta.de>
---
 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
-

Yeah, this looks reasonable.
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

-

IMHO not required:
config SOFTWARE_SUSPEND

	bool "Software Suspend (Hibernation)"

	depends on PM && SWAP
This would give you "trying to assign nonexistent symbol SUSPEND_POSSIBLE"

kconfig warnings on architectures without SUSPEND_POSSIBLE.
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 handles the dependency of SOFTWARE_SUSPEND on HOTPLUG_CPU

automatically without the user requiring to know about it.
Thanks to Stefan Richter and Linus Torvalds for valuable feedback.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
 arch/i386/Kconfig    |   16 +++++++++++-----

 arch/powerpc/Kconfig |   11 +++++++++--

 arch/x86_64/Kconfig  |   19 ++++++++++++-------

 kernel/power/Kconfig |   23 +++++++++++++++++------

 4 files changed, 49 insertions(+), 20 deletions(-)
commit bb14e6721dc4e1a97efbfa5398d6021b321af52d

Author: Adrian Bunk <bunk@stusta.de>

Date:   Sat Jul 28 06:47:03 2007 +0200
    asdf
diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig

index abb582b..eb00a12 100644

--- a/arch/i386/Kconfig

+++ b/arch/i386/Kconfig

@@ -903,13 +903,19 @@ config PHYSICAL_ALIGN
 	  Don't change this unless you know what you are doing.
-config HOTPLUG_CPU

-	bool "Support for suspend on SMP and hot-pluggable CPUs (EXPERIMENTAL)"

+config HOTPLUG_CPU_POSSIBLE

+	bool

 	depends on SMP && HOTPLUG && EXPERIMENTAL && !X86_VOYAGER

+	select SUSPEND_SMP_POSSIBLE

+	default y

+

+config HOTPLUG_CPU

+	bool "Support for hot-pluggable CPUs (EXPERIMENTAL)" if !SUSPEND_SMP

+	depends on HOTPLUG_CPU_POSSIBLE

+	default y if SUSPEND_SMP

 	---help---

-	  Say Y here to experiment with turning CPUs off and on, and to

-	  enable suspend on SMP systems. CPUs can be controlled through

-	  /sys/devices/system/cpu.

+	  Say Y here to experiment with turning CPUs off and on.

+	  CPUs can be controlled through...
[ message continues ]

Unless /all/ architectures define it, of course.

--

Stefan Richter

-=====-=-=== -=== ===--

http://arcgraph.de/sr/

-

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
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/

-

We can figure out ourselves when HOTPLUG_CPU is required, so there's no 
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
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
-

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

-

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/

-

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.   =20
Thanks,

--=20

S=C3=A9rgio M. B.

That should not depend on SOFTWARE_SUSPEND (it's equivalent to HIBERNATION).
Greetings,

Rafael
--

"Premature optimization is the root of all evil." - Donald Knuth

-

Even if I want to SUSPEND* to <something> I can't on my Dell Precision 530 boxes ,

SCSI is broken with suspend therefore all these boxes have the whole SUSPEND* off,

all I need is ACPI.
So why you think I want to have this all enabled by default now ?

Just to bloat the kernel with something doesn't even work for me ?
And I don't get from where you have the '99%' thing ?
But in this case some config / new config is better.
I do not need ACPI to SUSPEND but to make the box work properly.
Ohh and isn't better to make 'ACPI_PROCESSOR  select SUSPEND_SMP and HOTPLUG_CPU if X86 && SMP' ?
...
config ACPI_PROCESSOR

        tristate "Processor"

        default y

        help

          This driver installs ACPI as the idle handler for Linux, and uses

          ACPI C2 and C3 processor states to save power, on systems that

          support it.  It is required by several flavors of cpufreq

          Performance-state drivers.
...
Gabriel
-

Linux is already way behind the competition on both STR and STD.

Disabling it because it doesn't work will makes this situation
Can you be specific about how much additional "bloat" your system
You also don't need a lot of other code in your kernel.
At some point the complexity of supporting more configuration options

out-weights the benefits of having them.  I have a pretty good idea

of the cost of maintaining the code.  So my question to you is

is what, exactly, is the benefit of having 2.6.22 CONFIG_ACPI_SLEEP=y
ACPI_PROCESSOR supports C-states and P-states and is not directly

related to support for system sleep states.  If your system is recent,

then it is likely that you want to enable this (and cpufreq) to save power --

even if you are not interested in system-wide sleep states.
-Len

-

All of CONFIG_HOTPLUG_CPU. 
Len, this is not about ACPI code. This is about CONFIG_HOTPLUG_CPU. Which

I don't want. And which you forced on me.
		Linus

-

Btw nothing about HOTPLUG_CPU now but something is broken.
do a defconfig , make menuconfig , disable ACPI , make , and you get :
...
In file included from arch/i386/kernel/acpi/cstate.c:16:

include/acpi/processor.h:90: error: expected specifier-qualifier-list before 'acpi_integer'

include/acpi/processor.h:108: error: expected specifier-qualifier-list before 'acpi_integer'

include/acpi/processor.h:131: error: expected specifier-qualifier-list before 'acpi_integer'

include/acpi/processor.h:149: error: expected specifier-qualifier-list before 'acpi_integer'

include/acpi/processor.h:205: error: expected specifier-qualifier-list before 'acpi_handle'

include/acpi/processor.h:319: warning: 'struct acpi_device' declared inside parameter list

include/acpi/processor.h:319: warning: its scope is only this definition or declaration, which is probably not what you want

include/acpi/processor.h:322: warning: 'struct acpi_device' declared inside parameter list

make[2]: *** [arch/i386/kernel/acpi/cstate.o] Error 1

make[1]: *** [arch/i386/kernel/acpi] Error 2
...
$ grep ACPI .config

# Power management options (ACPI, APM)

# CONFIG_ACPI is not set

CONFIG_ACPI_PROCESSOR=y

CONFIG_X86_ACPI_CPUFREQ=y

CONFIG_X86_POWERNOW_K8_ACPI=y

CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
Gabriel

-

Heh what else can I do ? The _bug_(s) are reporter for ages.
See this one as example ( this kills all my Dells ) and there are a lot more reported.
http://bugzilla.kernel.org/show_bug.cgi?id=3062
...
 Description From Nathan Bryant 2004-07-13 18:14
...
Notice '2004' and still no one really cares .. 
At least I was not forced to use HOTPLUG_CPU .. 
Oh ok.
Well then add a dummy config onpion, ACPI_DESKTOP_SUSPEND or something , move the 2 selects to there ,

make it visible in the menu and make it even default y but that way one can disable it.
Gabriel

-

I want SMP, dammit. This machine has multi-core. And I want ACPI. I just

don't want the system sleep thing.
That wasn't true before, and it makes no sense what-so-ever as an

assumption.
The system sleep states are mostly usable on laptops. Not always even

then. They are seldom used on desktops or servers, but both of those are

often SMP machines, and certainly want ACPI.
But why the *hell* is this dependent on ACPI?
Why not just do ACPI_SLEEP, and have *that* do "select 
That makes no sense. You're tying together things that have *nothing* to

do with each other.
As mentioned (and as is *obvious*), pretty much everybody who has a

multi-core CPU on x86 wants ACPI and SMP. But the set of people who want

to sw-suspend such a machine is *much* smaller. There is no 99%.
			Linus

-

This seems to break ia64 defconfig:
   Building modules, stage 2.

   MODPOST 157 modules

FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.

Fix definition of struct acpi_device_id in mod_devicetable.h

make[2]: *** [__modpost] Error 1

make[1]: *** [modules] Error 2

make: *** [_all] Error 2
gcc 3.3.6, binutils 2.15.94
http://l4x.org/k/?d=32569
Jan

-

Are you cross-compiling?  The definition of kernel_ulong_t won't work on

x86.
Andreas.
--

Andreas Schwab, SuSE Labs, schwab@suse.de

SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany

PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

"And now for something completely different."

-

Yes, sorry, should have mentioned that. Build system is x86. Still,

it didn't happen before the recent acpi merge.
Jan

-

I also have the same error, which I didn't have in 2.6.22:
FATAL: drivers/acpi/ac: sizeof(struct acpi_device_id)=20 is not a

modulo of the size of section __mod_acpi_device_table=48.

Fix definition of struct acpi_device_id in mod_devicetable.h

make[1]: *** [__modpost] Error 1
Build system is x86_64. I'm not cross-compiling, as the target machine

(not the build machine) is also x86_64.
 - Yasha

-

This is strange, I just compiled on a IA64 with button as module

(defconfig), but with gcc version 4.1.2, all is fine.

Anyone an idea how to run into that?
I won't be able to detailed debug this before Monday, but be sure I will

do so then.
Thanks,
    Thomas
-