The current implementation of create_irq() is a hack but it is the
current hack that msi.c uses, and unfortunately the ``generic'' apic
msi ops depend on this hack. Thus we are stuck this hack of assuming
irq == vector until the depencencies in the generic msi code are removed.
Signed-off-by: Eric W. Biederman <[email protected]>
---
arch/i386/kernel/io_apic.c | 48 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 16966f4..04f78ff 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -2497,6 +2497,54 @@ static int __init ioapic_init_sysfs(void
device_initcall(ioapic_init_sysfs);
+#ifdef CONFIG_PCI_MSI
+/*
+ * Dynamic irq allocate and deallocation for MSI
+ */
+int create_irq(void)
+{
+ /* Hack of the day: irq == vector.
+ *
+ * Ultimately this will be be more general,
+ * and not depend on the irq to vector identity mapping.
+ * But this version is needed until msi.c can cope with
+ * the more general form.
+ */
+ int irq, vector;
+ unsigned long flags;
+ vector = assign_irq_vector(AUTO_ASSIGN);
+ irq = vector;
+
+ if (vector >= 0) {
+ struct irq_desc *desc;
+
+ spin_lock_irqsave(&vector_lock, flags);
+ vector_irq[vector] = irq;
+ irq_vector[irq] = vector;
+ spin_unlock_irqrestore(&vector_lock, flags);
+
+ set_intr_gate(vector, interrupt[irq]);
+
+ dynamic_irq_init(irq);
+ }
+ return irq;
+}
+
+void destroy_irq(unsigned int irq)
+{
+ unsigned long flags;
+ unsigned int vector;
+
+ dynmic_irq_cleanup(irq);
+
+ spin_lock_irqsave(&vector_lock, flags);
+ vector = irq_vector[irq];
+ vector_irq[vector] = -1;
+ irq_vector[irq] = 0;
+ spin_unlock_irqrestore(&vector_lock, flags);
+}
+#endif /* CONFIG_PCI_MSI */
+
/* --------------------------------------------------------------------------
ACPI-based IOAPIC Configuration
-------------------------------------------------------------------------- */
--
1.4.0.gc07e
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]