mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
	"Darrick J. Wong" <djwong@us.ibm.com>,
	Muli Ben-Yehuda <muli@il.ibm.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Joerg Roedel <joerg.roedel@amd.com>,
	Yinghai Lu <yhlu.kernel@gmail.com>,
	"Jon D. Mason" <jdmason@kudzu.us>,
	Corinna Schultz <coschult@us.ibm.com>,
	Ingo Molnar <mingo@elte.hu>
Subject: [11/18] x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree
Date: Wed, 16 Dec 2009 16:46:02 -0800	[thread overview]
Message-ID: <20091217004708.549421595@mini.kroah.org> (raw)
In-Reply-To: <20091217005306.GA6230@kroah.com>

2.6.27-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Darrick J. Wong <djwong@us.ibm.com>

commit 4528752f49c1f4025473d12bc5fa9181085c3f22 upstream.

On a multi-node x3950M2 system, there's a slight oddity in the
PCI device tree for all secondary nodes:

 30:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
  \-33:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
     \-34:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

...as compared to the primary node:

 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
  \-01:00.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
 03:00.0 PCI bridge: IBM CalIOC2 PCI-E Root Port (rev 01)
  \-04:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)

In both nodes, the LSI RAID controller hangs off a CalIOC2
device, but on the secondary nodes, the BIOS hides the VGA
device and substitutes the device tree ending with the disk
controller.

It would seem that Calgary devices don't necessarily appear at
the top of the PCI tree, which means that the current code to
find the Calgary IOMMU that goes with a particular device is
buggy.

Rather than walk all the way to the top of the PCI
device tree and try to match bus number with Calgary descriptor,
the code needs to examine each parent of the particular device;
if it encounters a Calgary with a matching bus number, simply
use that.

Otherwise, we BUG() when the bus number of the Calgary doesn't
match the bus number of whatever's at the top of the device tree.

Extra note: This patch appears to work correctly for the x3950
that came before the x3950 M2.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Acked-by: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Jon D. Mason <jdmason@kudzu.us>
Cc: Corinna Schultz <coschult@us.ibm.com>
LKML-Reference: <20091202230556.GG10295@tux1.beaverton.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/pci-calgary_64.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -377,13 +377,15 @@ static inline struct iommu_table *find_i
 
 	pdev = to_pci_dev(dev);
 
+	/* search up the device tree for an iommu */
 	pbus = pdev->bus;
-
-	/* is the device behind a bridge? Look for the root bus */
-	while (pbus->parent)
+	do {
+		tbl = pci_iommu(pbus);
+		if (tbl && tbl->it_busno == pbus->number)
+			break;
+		tbl = NULL;
 		pbus = pbus->parent;
-
-	tbl = pci_iommu(pbus);
+	} while (pbus);
 
 	BUG_ON(tbl && (tbl->it_busno != pbus->number));
 



  parent reply	other threads:[~2009-12-17  0:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-17  0:53 [00/18] 2.6.27.42-stable review Greg KH
2009-12-17  0:45 ` [01/18] signal: Fix alternate signal stack check Greg KH
2009-12-17  0:45 ` [02/18] debugfs: fix create mutex racy fops and private data Greg KH
2009-12-17  0:45 ` [03/18] firewire: ohci: handle receive packets with a data length of zero Greg KH
2009-12-17  0:45 ` [04/18] fuse: reject O_DIRECT flag also in fuse_create Greg KH
2009-12-17  1:36   ` David Daney
2009-12-17  4:15     ` Greg KH
2009-12-17  0:45 ` [05/18] hfs: fix a potential buffer overflow Greg KH
2009-12-17  0:45 ` [06/18] pata_hpt{37x|3x2n}: fix timing register masks (take 2) Greg KH
2009-12-17  0:45 ` [07/18] ssb: Fix range check in sprom write Greg KH
2009-12-17  0:45 ` [08/18] V4L/DVB: Fix test in copy_reg_bits() Greg KH
2009-12-17  0:46 ` [09/18] x86, apic: Enable lapic nmi watchdog on AMD Family 11h Greg KH
2009-12-17  0:46 ` [10/18] x86: ASUS P4S800 reboot=bios quirk Greg KH
2009-12-17  0:46 ` Greg KH [this message]
2009-12-17  0:46 ` [12/18] x86: Fix iommu=nodac parameter handling Greg KH
2009-12-17  0:46 ` [13/18] x86: GART: pci-gart_64.c: Use correct length in strncmp Greg KH
2009-12-17  0:46 ` [14/18] [IA64] fix csum_ipv6_magic() Greg KH
2009-12-17  0:46 ` [15/18] USB: fix mos7840 problem with minor numbers Greg KH
2009-12-17  0:46 ` [16/18] backlight: lcd - Fix wrong sizeof Greg KH
2009-12-17  0:46 ` [17/18] jffs2: Fix long-standing bug with symlink garbage collection Greg KH
2009-12-17  0:46 ` [18/18] matroxfb: fix problems with display stability Greg KH

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=20091217004708.549421595@mini.kroah.org \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=coschult@us.ibm.com \
    --cc=djwong@us.ibm.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jdmason@kudzu.us \
    --cc=joerg.roedel@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=muli@il.ibm.com \
    --cc=stable-review@kernel.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yhlu.kernel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®