Re: [PATCH] x86/sfi: fix ioapic gsi range

[ebiederm@xmission.com (Eric W. Biederman)]

jacob pan <jacob.jun.pan@linux.intel.com> writes:

> [jacob pan] 
>
> In arch/x86/kernel/mrst.c we parse SFI MTMR table then
> add timer irqs to mp_irqs. what is broken by this patch is
> pin_2_irq() lookup for the legacy irq range since we want
> NR_IRQS_LEGACY to be 0 on Moorestown. We do have the assumption that
> mp_irqs from SFI is 1:1 mapped to IRQs.

NR_IRQS_LEGACY is a constant of 16.

> Doing this can fix the problem, but you mentioned you have to use
> NR_IRQS_LEGACY, which i still don't understand.

Looking at the code in io_apic.c there is a relatively clean way to
handle this.  The actual concept in io_apic.c today is mp_bus_not_pci.

So you just need to do:

diff --git a/arch/x86/kernel/mrst.c b/arch/x86/kernel/mrst.c
index e796448..9377fda 100644
--- a/arch/x86/kernel/mrst.c
+++ b/arch/x86/kernel/mrst.c
@@ -242,4 +242,5 @@ void __init x86_mrst_early_setup(void)
 	x86_init.mpparse.find_smp_config = x86_init_noop;
 	x86_init.mpparse.get_smp_config = x86_init_uint_noop;
 
+	set_bit(0, mp_bus_not_pci);
 }


Then you get treated as ISA for purposes of pin_2_irq, and everything
is a pass through.  Since that seems to be what you want anyway I don't
see a problem with that for now.

Using legacy pic to even talk about this behavior is wrong as that is
hardware abstraction and the presence or absence of an i8259 has
nothing to do with the presence of ISA irqs and their descendants.

Eric