Hi
Build fails with:
drivers/acpi/sleep.c: In function `acpi_system_suspend':
drivers/acpi/sleep.c:209: warning: implicit declaration of function `do_suspend_lowlevel'
drivers/acpi/sleep.c: In function `acpi_sleep_init':
drivers/acpi/sleep.c:707: `sysrq_acpi_poweroff_op' undeclared (first use in this function)
drivers/acpi/sleep.c:707: (Each undeclared identifier is reported only once
drivers/acpi/sleep.c:707: for each function it appears in.)
The structure declaration is protected by
#if defined(CONFIG_MAGIC_SYSRQ) && defined(CONFIG_PM)
on line 640.
Config file attached.
--
Kind regards,
Robert Varga
------------------------------------------------------------------------------
[email protected] http://hq.sk/~nite/gpgkey.txt
On Thursday 31 October 2002 20:45, Robert Varga wrote:
> The structure declaration is protected by
>
> #if defined(CONFIG_MAGIC_SYSRQ) && defined(CONFIG_PM)
>
> on line 640.
At the moment CONFIG_PM seems to be enabling APM, though it clearly does more than that. I think the config options for ACPI and APM should be sorted out sooner or later. Just enable Power Management and this should compile.
Jos
After some more puzzling, it becomes clear that much more ACPI code should rely on CONFIG_PM. (Sleep.c should not be compiled in at all without CONFIG_PM) As the ACPI guys seem awake, I assume this will be fixed soon. For now: don't forget to enable CONFIG_PM (Power Management in the root of ACPI / APM configuration)
Jos
On Thursday 31 October 2002 20:45, Robert Varga wrote:
> Hi
>
> Build fails with:
>
> drivers/acpi/sleep.c: In function `acpi_system_suspend':
> drivers/acpi/sleep.c:209: warning: implicit declaration of function
> `do_suspend_lowlevel' drivers/acpi/sleep.c: In function `acpi_sleep_init':
> drivers/acpi/sleep.c:707: `sysrq_acpi_poweroff_op' undeclared (first use in
> this function) drivers/acpi/sleep.c:707: (Each undeclared identifier is
> reported only once drivers/acpi/sleep.c:707: for each function it appears
> in.)
>
> The structure declaration is protected by
>
> #if defined(CONFIG_MAGIC_SYSRQ) && defined(CONFIG_PM)
>
> on line 640.
>
> Config file attached.
> From: Jos Hulzink [mailto:[email protected]]
> After some more puzzling, it becomes clear that much more
> ACPI code should rely on CONFIG_PM. (Sleep.c should not be
> compiled in at all without CONFIG_PM) As the ACPI guys seem
> awake, I assume this will be fixed soon. For now: don't
> forget to enable CONFIG_PM (Power Management in the root of
> ACPI / APM configuration)
ACPI implements PM but that's not all it implements. Is making CONFIG_PM
true if ACPI or APM are on a viable option? I think that would more
accurately reflect reality.
Or can we get rid of CONFIG_PM?
Regards -- Andy
On Fri, Nov 01, 2002 at 11:37:26AM -0800, Grover, Andrew wrote:
> ACPI implements PM but that's not all it implements. Is making CONFIG_PM
> true if ACPI or APM are on a viable option? I think that would more
> accurately reflect reality.
>
> Or can we get rid of CONFIG_PM?
I'm not sure of places that do it off the top of my head, but
CONFIG_PM would save us having to do ugly CONFIG_APM || CONFIG_ACPI
tests.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Friday 01 November 2002 20:47, Dave Jones wrote:
> On Fri, Nov 01, 2002 at 11:37:26AM -0800, Grover, Andrew wrote:
> > ACPI implements PM but that's not all it implements. Is making CONFIG_PM
> > true if ACPI or APM are on a viable option? I think that would more
> > accurately reflect reality.
> >
> > Or can we get rid of CONFIG_PM?
>
> I'm not sure of places that do it off the top of my head, but
> CONFIG_PM would save us having to do ugly CONFIG_APM || CONFIG_ACPI
> tests.
This seems to be true from what I have seen of the source so far.
I'm thinking....
ACPI is more than Power Management. The fact that a system supports ACPI does
not mean that the user wants to use power management. On the other hand, I
see no reason why a user does NOT want a system to auto poweroff, and sleep
and suspend are easy to configure in BIOS, or by linux tools. (Does Linux
take over the BIOS settings for suspend & sleep ? Don't use them, so
donnow....) What I wanna say: I think it is okay if CONFIG_PM is replaced by
CONFIG_APM || CONFIG_ACPI
Other issue: Are ACPI and APM not mutually exclusive ? If so, I would propose
a selection box: <ACPI> <APM> <none> with related options shown below. Hmzz..
there the issue of the fact that ACPI is more than power management shows up
again.
And well... CONFIG_APM || CONFIG_ACPI might look ugly to you, I think it isn't
that bad, besides, you gain a lot from the configuration side. IMHO
configuring the kernel has become hard enough with the new input layer
already :( Maybe it is time for a "[ ] show expert options" in the
configuration tool...
Jos
On Fri, Nov 01, 2002 at 10:21:56PM +0100, Jos Hulzink wrote:
> Other issue: Are ACPI and APM not mutually exclusive ? If so, I would propose
> a selection box: <ACPI> <APM> <none> with related options shown below. Hmzz..
> there the issue of the fact that ACPI is more than power management shows up
> again.
Whilst they can't both run at the same time, it's perfectly possible
(and useful) to build a kernel with both included. ACPI will quit
if APM is already running, so booting with apm=off turns the same
kernel into 'ACPI mode'
Quite useful for me right now, as currently my Vaio won't boot
an ACPI kernel if its on mains power for some reason. 8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Friday 01 November 2002 21:31, Dave Jones wrote:
> On Fri, Nov 01, 2002 at 10:21:56PM +0100, Jos Hulzink wrote:
> > Other issue: Are ACPI and APM not mutually exclusive ? If so, I would
> > propose a selection box: <ACPI> <APM> <none> with related options shown
> > below. Hmzz.. there the issue of the fact that ACPI is more than power
> > management shows up again.
>
> Whilst they can't both run at the same time, it's perfectly possible
> (and useful) to build a kernel with both included. ACPI will quit
> if APM is already running, so booting with apm=off turns the same
> kernel into 'ACPI mode'
Hmzz.. in that case I vote for dropping CONFIG_PM in favour of CONFIG_APM || CONFIG_ACPI, even though it requires some more typing for the programmers. (I'm no ACPI programmer, so I don't care ;-)
Jos
On Sat, 2 Nov 2002, Jos Hulzink wrote:
> On Friday 01 November 2002 21:31, Dave Jones wrote:
> > On Fri, Nov 01, 2002 at 10:21:56PM +0100, Jos Hulzink wrote:
> > > Other issue: Are ACPI and APM not mutually exclusive ? If so, I would
> > > propose a selection box: <ACPI> <APM> <none> with related options shown
> > > below. Hmzz.. there the issue of the fact that ACPI is more than power
> > > management shows up again.
> >
> > Whilst they can't both run at the same time, it's perfectly possible
> > (and useful) to build a kernel with both included. ACPI will quit
> > if APM is already running, so booting with apm=off turns the same
> > kernel into 'ACPI mode'
> Hmzz.. in that case I vote for dropping CONFIG_PM in favour of
> CONFIG_APM || CONFIG_ACPI, even though it requires some more typing for
> the programmers. (I'm no ACPI programmer, so I don't care ;-)
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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
[email protected] 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.
Er, there's no reason why PM even on Intel hardware should be restricted to
ACPI and APM. 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.
--
dwmw2
On Wed, 6 Nov 2002, David Woodhouse wrote:
>
> [email protected] 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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.