[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1631ue5ho.fsf@fess.ebiederm.org>
Date: Mon, 07 Jun 2010 17:24:19 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>
Cc: Alan Cox <alan@...ux.intel.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
Feng Tang <feng.tang@...el.com>,
Len Brown <len.brown@...el.com>
Subject: Re: [PATCH] x86/sfi: fix ioapic gsi range
Jacob Pan <jacob.jun.pan@...ux.intel.com> writes:
> SFI based platforms should have zero based gsi_base for IOAPICs found in SFI
> tables. The current code sets gsi_base starting from 1 when registering ioapic.
> The result is that Moorestown platform would have wrong mp_gsi_routing for each
> ioapic.
Yes starting at 1 is a bug.
> Background:
> In Moorestown/Medfield platforms, there is no legacy IRQs, all gsis and irqs
> are one to one mapped, including those < 16. Specifically, IRQ0 and IRQ1 are
> used for per-cpu timers. So without this patch, IOAPIC pin to IRQ mapping is
> off by one.
The patch looks mostly reasonable the comment is wrong.
You may not use a 1-1 mapping if you don't have legacy irqs. Linux
irqs 0-15 are the ISA irqs you may not use those irq numbers for
something different on any architecture, but especially not on x86.
The gsi numbers are firmware specific and you may treat however you want.
Does the following patch work for you?
It appears I goofed when it was pointed out that gsi_end was inclusive and
didn't change the initialize.
Eric
---
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 33f3563..5de84e5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -90,7 +90,7 @@ int nr_ioapics;
struct mp_ioapic_gsi mp_gsi_routing[MAX_IO_APICS];
/* The last gsi number used */
-u32 gsi_end;
+u32 gsi_end = -1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists