2.6.24 x86 apm module name change not in Kconfig

2.6.24 x86 apm module name change not in Kconfig

[A.E.Lawrence]

Legacy i386 box failed to shutdown under 2.6.24 because it tried to load
module apm rather than apm_32.

If it is intended that apm_32 not be aliased as apm, then
 arch/x86/Kconfig
which currently says "module will be called apm."
needs to be updated to match.

ael

2.6.24 x86 apm module name change not in Kconfig

[A.E.Lawrence]

Legacy i386 box failed to shutdown under 2.6.24 because it tried to load
module apm rather than apm_32.

If it is intended that apm_32 not be aliased as apm, then
 arch/x86/Kconfig
which currently says "module will be called apm."
needs to be updated to match.

ael

[PATCH] x86: restore correct module name for apm

[Sam Ravnborg]

The apm module were renamed to apm_32 during the merge of 32 and 64 bit x86 which
is unfortunate.
As apm is 32 bit specific we like to keep the _32 in the filename
but the module should be named apm.

Fix this in the Makefile.
Reported by "A.E.Lawrence" <lawrence_a_e@ntlworld.com>

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "A.E.Lawrence" <lawrence_a_e@ntlworld.com>
---

build tested only but obviously correct.

	Sam

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 6f81300..f080635 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -37,7 +37,8 @@ obj-$(CONFIG_X86_MSR)		+= msr.o
 obj-$(CONFIG_X86_CPUID)		+= cpuid.o
 obj-$(CONFIG_MICROCODE)		+= microcode.o
 obj-$(CONFIG_PCI)		+= early-quirks.o
-obj-$(CONFIG_APM)		+= apm_32.o
+apm-y				:= apm_32.o
+obj-$(CONFIG_APM)		+= apm.o
 obj-$(CONFIG_X86_SMP)		+= smp_$(BITS).o smpboot_$(BITS).o tsc_sync.o
 obj-$(CONFIG_X86_32_SMP)	+= smpcommon_32.o
 obj-$(CONFIG_X86_64_SMP)	+= smp_64.o smpboot_64.o tsc_sync.o

Re: [PATCH] x86: restore correct module name for apm

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> The apm module were renamed to apm_32 during the merge of 32 and 64 
> bit x86 which is unfortunate. As apm is 32 bit specific we like to 
> keep the _32 in the filename but the module should be named apm.
> 
> Fix this in the Makefile.

thanks, applied.

	Ingo

Re: [PATCH] x86: restore correct module name for apm

[Frans Pop]

Sam Ravnborg wrote:
> The apm module were renamed to apm_32 during the merge of 32 and 64 bit
> x86 which is unfortunate.
> As apm is 32 bit specific we like to keep the _32 in the filename
> but the module should be named apm.
> 
> Fix this in the Makefile.
> Reported by "A.E.Lawrence" <lawrence_a_e@ntlworld.com>
> 
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: "A.E.Lawrence" <lawrence_a_e@ntlworld.com>

I assume this will be pushed for stable 2.6.24 as well?

Cheers,
FJP

Re: [PATCH] x86: restore correct module name for apm

[A.E.Lawrence]

Sam Ravnborg wrote:
> The apm module were renamed to apm_32 during the merge of 32 and 64 bit x86 which
> is unfortunate.
> As apm is 32 bit specific we like to keep the _32 in the filename
> but the module should be named apm.
> 
> Fix this in the Makefile.
> Reported by "A.E.Lawrence" <lawrence_a_e@ntlworld.com>

..snip..
> 
> build tested only but obviously correct.
> 
> 	Sam

It is also at
  http://bugzilla.kernel.org/show_bug.cgi?id=9877
which someone (me?) should probably now close.

A E Lawrence

Re: [PATCH] x86: restore correct module name for apm

[Sam Ravnborg]

On Sun, Feb 03, 2008 at 11:52:16AM +0000, A.E.Lawrence wrote:
> Sam Ravnborg wrote:
> > The apm module were renamed to apm_32 during the merge of 32 and 64 bit x86 which
> > is unfortunate.
> > As apm is 32 bit specific we like to keep the _32 in the filename
> > but the module should be named apm.
> > 
> > Fix this in the Makefile.
> > Reported by "A.E.Lawrence" <lawrence_a_e@ntlworld.com>
> 
> ..snip..
> > 
> > build tested only but obviously correct.
> > 
> > 	Sam
> 
> It is also at
>   http://bugzilla.kernel.org/show_bug.cgi?id=9877
> which someone (me?) should probably now close.

I please do so.
But I think you should wait until it hits mainline

	Sam