All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Raghavendra D Prabhu <rprabhu@wnohang.net>
Cc: Ian Campbell <ijc@hellion.org.uk>,
	linux-kernel@vger.kernel.org, jeremy.fitzhardinge@citrix.com,
	xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [TOME] Re: [PATCH] Modpost section mismatch fix
Date: Tue, 5 Jul 2011 17:32:43 -0400	[thread overview]
Message-ID: <20110705213243.GA3647@dumpdata.com> (raw)
In-Reply-To: <20110705144846.GA13548@dumpdata.com>

On Tue, Jul 05, 2011 at 10:48:46AM -0400, Konrad Rzeszutek Wilk wrote:
> > >>xen_register_gsi and hence, xen_register_pirq are called from
> > >>init (with xen_setup_acpi_sci) and non-init (with
> > >>acpi_register_gsi_xen); since xen_set_acpi_sci calls it with gsi ==
> > >>acpi_sci_override_gsi and is marked __init, the best way would be to
> > >>call xen_register_gsi and xen_register_pirq with a boolean argument like
> > >>sci_override to obviate the need to use acpi_sci_override_gsi in
> > >>register_pirq. I will send the patch with this change if it looks good.
> > >
> > >Hold on, let me rebase #stable/pci.cleanups and see if the issue
> > >here disappears.
> > Thanks, will wait until the rebase and test after that.
> 
> Hm, it actually looks like it wont do the trick. Why don't you send
> a patch against 3.0-rc6 with the outlined mechanism mentioned above.

Or this patch (against 3.0-rc6) might do the trick:

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index fe00830..f567965 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -327,13 +327,12 @@ int __init pci_xen_hvm_init(void)
 }
 
 #ifdef CONFIG_XEN_DOM0
-static int xen_register_pirq(u32 gsi, int triggering)
+static int xen_register_pirq(u32 gsi, int gsi_override, int triggering)
 {
 	int rc, pirq, irq = -1;
 	struct physdev_map_pirq map_irq;
 	int shareable = 0;
 	char *name;
-	bool gsi_override = false;
 
 	if (!xen_pv_domain())
 		return -1;
@@ -345,31 +344,12 @@ static int xen_register_pirq(u32 gsi, int triggering)
 		shareable = 1;
 		name = "ioapic-level";
 	}
-
 	pirq = xen_allocate_pirq_gsi(gsi);
 	if (pirq < 0)
 		goto out;
 
-	/* Before we bind the GSI to a Linux IRQ, check whether
-	 * we need to override it with bus_irq (IRQ) value. Usually for
-	 * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
-	 * but there are oddballs where the IRQ != GSI:
-	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
-	 * which ends up being: gsi_to_irq[9] == 20
-	 * (which is what acpi_gsi_to_irq ends up calling when starting the
-	 * the ACPI interpreter and keels over since IRQ 9 has not been
-	 * setup as we had setup IRQ 20 for it).
-	 */
-	if (gsi == acpi_sci_override_gsi) {
-		/* Check whether the GSI != IRQ */
-		acpi_gsi_to_irq(gsi, &irq);
-		if (irq != gsi)
-			/* Bugger, we MUST have that IRQ. */
-			gsi_override = true;
-	}
-	if (gsi_override)
-		irq = xen_bind_pirq_gsi_to_irq(irq, pirq, shareable, name);
+	if (gsi_override >= 0)
+		irq = xen_bind_pirq_gsi_to_irq(gsi_override, pirq, shareable, name);
 	else
 		irq = xen_bind_pirq_gsi_to_irq(gsi, pirq, shareable, name);
 	if (irq < 0)
@@ -392,7 +372,7 @@ out:
 	return irq;
 }
 
-static int xen_register_gsi(u32 gsi, int triggering, int polarity)
+static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
 {
 	int rc, irq;
 	struct physdev_setup_gsi setup_gsi;
@@ -403,7 +383,7 @@ static int xen_register_gsi(u32 gsi, int triggering, int polarity)
 	printk(KERN_DEBUG "xen: registering gsi %u triggering %d polarity %d\n",
 			gsi, triggering, polarity);
 
-	irq = xen_register_pirq(gsi, triggering);
+	irq = xen_register_pirq(gsi, gsi_override, triggering);
 
 	setup_gsi.gsi = gsi;
 	setup_gsi.triggering = (triggering == ACPI_EDGE_SENSITIVE ? 0 : 1);
@@ -425,6 +405,8 @@ static __init void xen_setup_acpi_sci(void)
 	int rc;
 	int trigger, polarity;
 	int gsi = acpi_sci_override_gsi;
+	int irq = -1;
+	int gsi_override = -1;
 
 	if (!gsi)
 		return;
@@ -441,7 +423,25 @@ static __init void xen_setup_acpi_sci(void)
 	printk(KERN_INFO "xen: sci override: global_irq=%d trigger=%d "
 			"polarity=%d\n", gsi, trigger, polarity);
 
-	gsi = xen_register_gsi(gsi, trigger, polarity);
+	/* Before we bind the GSI to a Linux IRQ, check whether
+	 * we need to override it with bus_irq (IRQ) value. Usually for
+	 * IRQs below IRQ_LEGACY_IRQ this holds IRQ == GSI, as so:
+	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
+	 * but there are oddballs where the IRQ != GSI:
+	 *  ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)
+	 * which ends up being: gsi_to_irq[9] == 20
+	 * (which is what acpi_gsi_to_irq ends up calling when starting the
+	 * the ACPI interpreter and keels over since IRQ 9 has not been
+	 * setup as we had setup IRQ 20 for it).
+	 */
+	/* Check whether the GSI != IRQ */
+	if (acpi_gsi_to_irq(gsi, &irq) == 0) {
+		if (irq >= 0 && irq != gsi)
+			/* Bugger, we MUST have that IRQ. */
+			gsi_override = irq;
+	}
+
+	gsi = xen_register_gsi(gsi, gsi_override, trigger, polarity);
 	printk(KERN_INFO "xen: acpi sci %d\n", gsi);
 
 	return;
@@ -450,7 +450,7 @@ static __init void xen_setup_acpi_sci(void)
 static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
 				 int trigger, int polarity)
 {
-	return xen_register_gsi(gsi, trigger, polarity);
+	return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
 }
 
 static int __init pci_xen_initial_domain(void)
@@ -489,7 +489,7 @@ void __init xen_setup_pirqs(void)
 		if (acpi_get_override_irq(irq, &trigger, &polarity) == -1)
 			continue;
 
-		xen_register_pirq(irq,
+		xen_register_pirq(irq, -1 /* no GSI override */,
 			trigger ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE);
 	}
 }

  reply	other threads:[~2011-07-05 21:33 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-03 23:25 [PATCH] Modpost section mismatch fix Raghavendra D Prabhu
2011-07-04  8:49 ` Ian Campbell
2011-07-04  8:49 ` Ian Campbell
2011-07-04  8:49   ` Ian Campbell
2011-07-04 22:16   ` Raghavendra D Prabhu
2011-07-04 22:16   ` Raghavendra D Prabhu
2011-07-05 14:13     ` Konrad Rzeszutek Wilk
2011-07-05 14:13       ` Konrad Rzeszutek Wilk
2011-07-05 14:27       ` [TOME] " Raghavendra D Prabhu
2011-07-05 14:48         ` Konrad Rzeszutek Wilk
2011-07-05 14:48           ` Konrad Rzeszutek Wilk
2011-07-05 21:32           ` Konrad Rzeszutek Wilk [this message]
2011-07-06  8:30             ` [Xen-devel] " Ian Campbell
2011-07-06  8:30             ` Ian Campbell
2011-07-07 15:46             ` Raghavendra D Prabhu
2011-07-07 15:46             ` Raghavendra D Prabhu
2011-07-07 16:24               ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-07-07 16:24                 ` Konrad Rzeszutek Wilk
2011-07-07 19:48                 ` [Xen-devel] " Raghavendra D Prabhu
2011-07-07 19:48                 ` Raghavendra D Prabhu
2011-07-07 20:09                   ` Konrad Rzeszutek Wilk
2011-07-07 20:09                   ` Konrad Rzeszutek Wilk
2011-07-07 21:04                     ` Raghavendra D Prabhu
2011-07-07 21:04                     ` Raghavendra D Prabhu
2011-07-08 20:26                       ` [Xen-devel] Re: [PATCH] Modpost section mismatch fix (for platform-pci-unplug.c) Konrad Rzeszutek Wilk
2011-07-08 20:26                       ` Konrad Rzeszutek Wilk
2011-07-09 16:29                         ` [TOME] " Raghavendra D Prabhu
2011-07-09 16:29                         ` Raghavendra D Prabhu
2011-07-11 10:47                         ` Stefano Stabellini
2011-07-11 10:47                         ` Stefano Stabellini
2011-07-07 16:24               ` [Xen-devel] Re: [PATCH] Modpost section mismatch fix Konrad Rzeszutek Wilk
2011-07-05 21:32           ` [TOME] " Konrad Rzeszutek Wilk
2011-07-05 14:48         ` Konrad Rzeszutek Wilk
2011-07-05 14:27       ` Raghavendra D Prabhu
2011-07-05 14:13     ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110705213243.GA3647@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=ijc@hellion.org.uk \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rprabhu@wnohang.net \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.