[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1r5n2wwah.fsf_-_@fess.ebiederm.org>
Date: Mon, 29 Mar 2010 16:19:34 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
linux-kernel@...r.kernel.org, Thomas Renninger <trenn@...e.de>,
Suresh Siddha <suresh.b.siddha@...el.com>, len.brown@...el.com,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>, linux-acpi@...r.kernel.org,
Iranna D Ankad <iranna.ankad@...ibm.com>,
Gary Hade <garyhade@...ibm.com>,
Natalie Protasevich <protasnb@...il.com>
Subject: [PATCH 0/14] Start coping gsis < 16 that are not isa irqs.
It appears there are a few systems in the wild that use acpi
interrupt source overrides to report a gsi > 16 is an isa irq.
This breaks all kinds of assumptions I figure any BIOS doing that
probably should be shot as that is very much not a conservative position.
That said acpi appears to allow this insanity and on the basis of being
liberal in what we accept we should try to do something reasonable, and
keep our notions of gsi, isa irq, and linux irq as straight as we can.
To that end this patchset slightly modifies the gsi to linux irq
mapping. Making it a 1 to 1 identity mapping except for the first 16
gsis. If those gsis are isa irqs (the typical and default acpi
configuration) they will be mapped into the first 16 irqs. If those
first 16 gsis are not isa irqs they will be given a linux irq number
just past the last gsi. Allowing us the chance to use them.
This patchset is my attempt to straighten out our understanding of which
kind of irq name is used where and the cleanups used to get there.
Thanks to Yinghai Lu <yinghai@...nel.org> for taking the first stab at
this and finding that there is a real world problem here. This patchset
is inspired by his work, but little of it remains the same.
This patchset lies in the weird world between the acpi and x86 and ia64.
Since most of the changes are x86 related I think it makes most sense
to go via the x86 tree.
Eric W. Biederman (14):
x86 acpi/irq: Introduce apci_isa_irq_to_gsi
x86 acpi/irq: Teach acpi_get_override_irq to take a gsi not an isa_irq
x86 acpi/irq: pci device dev->irq is an isa irq not a gsi
x86 acpi/irq: Fix acpi_sci_ioapic_setup so it has both bus_irq and gsi
x86 acpi/irq: Generalize mp_config_acpi_legacy_irqs
x86 ioapic: Only export mp_find_ioapic and mp_find_ioapic_pin in io_apic.h
x86 ioapic: Fix the types of gsi values
x86 ioapic: Teach mp_register_ioapic to compute a global gsi_end
x86 ioapic: In mpparse use mp_register_ioapic
x86 ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic.
x86 ioapic: Optimize pin_2_irq
x86 ioapic: Simplify probe_nr_irqs_gsi.
x86 acpi/irq: Handle isa irqs that are not identity mapped to gsi's.
x86 irq: Kill io_apic_renumber_irq
arch/ia64/kernel/acpi.c | 8 ++
arch/x86/include/asm/io_apic.h | 12 ++--
arch/x86/include/asm/mpspec.h | 10 ---
arch/x86/kernel/acpi/boot.c | 133 ++++++++++++++++++++++++--------------
arch/x86/kernel/apic/es7000_32.c | 19 ------
arch/x86/kernel/apic/io_apic.c | 93 +++++++++++---------------
arch/x86/kernel/mpparse.c | 25 +-------
arch/x86/kernel/sfi.c | 4 +-
drivers/acpi/pci_irq.c | 8 ++-
include/linux/acpi.h | 5 +-
10 files changed, 149 insertions(+), 168 deletions(-)
Eric
--
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