Re: [2.6.31.13] Build failure at arch/x86/kernel/apic/io_apic.c

From: Yinghai
Date: Mon May 03 2010 - 13:53:17 EST


On 05/03/2010 10:44 AM, Greg KH wrote:
> On Mon, May 03, 2010 at 10:16:06AM -0700, Yinghai wrote:
>> On 05/01/2010 11:07 AM, Greg KH wrote:
>>> On Mon, Apr 12, 2010 at 01:10:59PM +0900, Tetsuo Handa wrote:
>>>> Commit d539e5576605d048e6aeb21cbe3a8e71dc5eea81 "x86: Fix SCI on IOAPIC != 0"
>>>> introduced "void setup_IO_APIC_irq_extra(u32 gsi)" which calls
>>>> mp_find_ioapic() and mp_find_ioapic_pin().
>>>>
>>>> This commit does not compile if CONFIG_X86_IO_APIC=y and CONFIG_ACPI=n .
>>>
>>> Why would you want to build without ACPI on any modern system? Anyway,
>>> have a fix for this?
>>>
>> maybe just put #ifdef CONFIG_ACPI around the callee etc?
>
> Ick. How was it solved upstream?
>

those two functions are moved to arch/x86/kernel/apic/io_apic.c

maybe you can put that patch to 2.6.31.xx?

YH

commit 2a4ab640d3c28c2952967e5f63ea495555bf2a5f
Author: Feng Tang <feng.tang@xxxxxxxxx>
Date: Tue Jul 7 23:01:15 2009 -0400

ACPI, x86: expose some IO-APIC routines when CONFIG_ACPI=n

Some IO-APIC routines are ACPI specific now, but need to
be exposed when CONFIG_ACPI=n for the benefit of SFI.

Remove #ifdef ACPI around these routines:

io_apic_get_unique_id(int ioapic, int apic_id);
io_apic_get_version(int ioapic);
io_apic_get_redir_entries(int ioapic);

Move these routines from ACPI-specific boot.c to io_apic.c:

uniq_ioapic_id(u8 id)
mp_find_ioapic()
mp_find_ioapic_pin()
mp_register_ioapic()

Also, since uniq_ioapic_id() is now no longer static,
re-name it to io_apic_unique_id() for consistency
with the other public io_apic routines.

For simplicity, do not #ifdef the resulting code ACPI || SFI,
thought that could be done in the future if it is important
to optimize the !ACPI !SFI IO-APIC x86 kernel for size.

Signed-off-by: Feng Tang <feng.tang@xxxxxxxxx>
Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
Cc: x86@xxxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/