public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <len.brown@intel.com>
To: Jason Uhlenkott <jasonuhl@sgi.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org,
	ACPI Developers <acpi-devel@lists.sourceforge.net>
Subject: Re: [ACPI] Re: 2.6.12-rc1-mm3
Date: 25 Mar 2005 23:12:39 -0500	[thread overview]
Message-ID: <1111810359.19919.113.camel@d845pe> (raw)
In-Reply-To: <20050326025704.GE207782@dragonfly.engr.sgi.com>

On Fri, 2005-03-25 at 21:57, Jason Uhlenkott wrote:
> On Fri, Mar 25, 2005 at 09:24:21PM -0500, Len Brown wrote:
> > What bad things happen if you define CONFIG_PM on SN2?
> 
> None, other than slightly enlarging the kernel with some
> suspend/resume stuff we don't care about.  It's always been
> unavailable for SN2 builds:
> 
> depends on IA64_GENERIC || IA64_DIG || IA64_HP_ZX1 ||
> IA64_HP_ZX1_SWIOTLB
> 
> but there doesn't appear to be any particular reason for that other
> than us not needing it (and in fact SN2 systems can run IA64_GENERIC
> kernels with CONFIG_PM enabled without incident).

good.

I realize now I didn't answer your original question.
The reason ACPI now depends on PM is that
it makes it easier for us to do a more orderly shutdown --
acpi registers as a device so it can do some stuff
upon the PM device shutdowns -- before interrupts are disabled.

I think with all the twisty turney passages
related to the suspend states, poweroff, sys-req, and now kexec,
that it is best if we can keep the code paths as
common as possible or some of them will never get the
testing needed to prevent them from getting broken.

Also, it is now common practice to include PM && ACPI together
in the x86 world.  Though technically one could have
ACPI w/o PM and you'd have lost only ACPI_SLEEP, virtually
nobody seems to use/depend-on that combination.

Obviously I hadn't considered SN2 or built its config
before that 1-liner.  I'll be sure to build it next time.

> > Re: CONFIG_ACPI_BOOT
> > I've got a patch that makes it go away -- this looks like
> > a good reason for me to dust it off...  Looks like
> > arch/ia64/Kconfig defines ACPI and then pulls in
> drivers/acpi/Kconfig,
> > which it should not do - it should look like i386/Kconfig...
> 
> Sounds good to me.  Does that mean everything currently controlled by
> CONFIG_ACPI_BOOT will be controlled by CONFIG_ACPI instead?

yes.  this was in -mm a while back, but got pushed onto the back
burner when more pressing things came up.

thanks,
-Len

  parent reply	other threads:[~2005-03-26  4:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050325002154.335c6b0b.akpm@osdl.org>
2005-03-26  1:43 ` 2.6.12-rc1-mm3 Jason Uhlenkott
     [not found]   ` <20050326014327.GB207782-MxuHJOjpcnauM61iycY1Zzbuus4N2nEH@public.gmane.org>
2005-03-26  1:56     ` 2.6.12-rc1-mm3 Len Brown
2005-03-26  2:02       ` [ACPI] " Jason Uhlenkott
     [not found]         ` <20050326020212.GC207782-MxuHJOjpcnauM61iycY1Zzbuus4N2nEH@public.gmane.org>
2005-03-26  2:24           ` Len Brown
2005-03-26  2:57             ` [ACPI] " Jason Uhlenkott
     [not found]               ` <20050326025704.GE207782-MxuHJOjpcnauM61iycY1Zzbuus4N2nEH@public.gmane.org>
2005-03-26  3:40                 ` Jesse Barnes
2005-03-26  4:12               ` Len Brown [this message]
2005-03-26  5:52                 ` Jason Uhlenkott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111810359.19919.113.camel@d845pe \
    --to=len.brown@intel.com \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=akpm@osdl.org \
    --cc=jasonuhl@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox