Messages in this thread | | | Date | Wed, 6 Nov 2002 11:33:15 -0500 (EST) | From | Bill Davidsen <> | Subject | Re: 2.5.45 build failed with ACPI turned on |
| |
On Wed, 6 Nov 2002, David Woodhouse wrote:
> > davidsen@tmr.com said: > > More to the point, define CONFIG_PM as ( CONFIG_APM | CONFIG_ACPI ) > > and be able to easily handle any new PM method on whatever hardware. > > PM is not limited to Intel hardware. Make a new HAS_PM if reusing > > CONFIG_PM creates problems.
Isn't this what I said? > > Er, there's no reason why PM even on Intel hardware should be restricted to > ACPI and APM.
That's what I proposed. Define CONFIG_PM as what we have now, or define a new HAS_PM define to indicate that PM is present in some form, and be able to add other schemes when/if they happen ("easily handle any new PM method"). Ex: #define HAS_PM ( CONFIG_ACPI | CONFIG_APM | CONFIG_IMTU ) One master symbol to indicate that PM is present in any form.
> With appropriate chipset documentation there's nothing to stop > people from writing proper driver code to enter sleep states, etc. for i386 > chipsets just as we have for other architectures.
Which could be handled by HAS_PM_SLEEP, HAS_PM_SUSPEND, HAS_PM_POWEROFF and the like, if that seems desirable.
I can't see this being totally non-messy, but the config could probably be clever and grey out anything which can't be done at all for the hardware selected.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |