From: Andrew Morton <akpm@linux-foundation.org>
To: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <ak@suse.de>,
Linux-Kernel <linux-kernel@vger.kernel.org>,
Jon Mason <jdmason@gmail.com>,
Murillo Fernandes Bernardes <bernarde@br.ibm.com>
Subject: Re: [PATCH x86-64] Calgary - Fix mis-handled PCI topology
Date: Fri, 3 Aug 2007 22:25:10 -0700 [thread overview]
Message-ID: <20070803222510.fe3156cf.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070802133926.GI25771@rhun.ibm.com>
On Thu, 2 Aug 2007 16:39:26 +0300 Muli Ben-Yehuda <muli@il.ibm.com> wrote:
> Andrew, can you please push this Calgary bug-fix to 2.6.23 in your
> next merge? it fixes a showstopper bug in the recently merged CalIOC2
> support that hits machines with multiple levels of PCI-to-PCI bridges.
>
> Thanks,
> Muli
> ---
> From: Murillo Fernandes Bernardes <bernarde@br.ibm.com>
> Subject: x86-64: Calgary - Fix mis-handled PCI topology
>
> Current code assumed that devices were directly connected to a Calgary
> bridge, as it tried to get the iommu table directly from the parent bus
> controller.
>
> When we have another bridge between the Calgary/CalIOC2 bridge and the
> device we should look upwards until we get to the top (Calgary/CalIOC2
> bridge), where the iommu table resides.
>
> Signed-off-by: Murillo Fernandes Bernardes <mfb@br.ibm.com>
> Signed-off-by: Muli Ben-Yehuda <muli@il.ibm.com>
>
> --
> diff -ruN linux-2.6.23-rc1.orig/arch/x86_64/kernel/pci-calgary.c linux-2.6.23-rc1/arch/x86_64/kernel/pci-calgary.c
> --- linux-2.6.23-rc1.orig/arch/x86_64/kernel/pci-calgary.c 2007-08-01 15:37:04.000000000 -0300
> +++ linux-2.6.23-rc1/arch/x86_64/kernel/pci-calgary.c 2007-08-01 15:48:55.000000000 -0300
> @@ -367,16 +367,15 @@
>
> pdev = to_pci_dev(dev);
>
> - /* is the device behind a bridge? */
> - if (unlikely(pdev->bus->parent))
> - pbus = pdev->bus->parent;
> - else
> - pbus = pdev->bus;
> + pbus = pdev->bus;
> +
> + /* is the device behind a bridge? Look for the root bus */
> + while (pbus->parent)
> + pbus = pbus->parent;
>
> tbl = pci_iommu(pbus);
>
> - BUG_ON(pdev->bus->parent &&
> - (tbl->it_busno != pdev->bus->parent->number));
> + BUG_ON(tbl && (tbl->it_busno != pbus->number));
>
> return tbl;
> }
>
hmm, sorry, I missed the this-is-urgent factor.
Andi, should I include this in my next batch to Linus?
btw, my list of "patches which should be in 2.6.23 but go via subsystem
maintainers" is presently
dma_free_coherent-needs-irqs-enabled-sigh.patch
usb-serial-fix-oti6858c-segfault-in-termios-handling.patch
sparsemem-ensure-we-initialise-the-node-mapping-for-sparsemem_static.patch
sparsemem-ensure-we-initialise-the-node-mapping-for-sparsemem_static-fix.patch
tpmdd-maintainers.patch
nfs-fix-put_nfs_open_context.patch
make-oprofile-call-shutdown-only-once-per-session.patch
perfctr_watchdog-do-not-bug_on-when-msr-is-unknown.patch
acpi-bay-send-envp-with-uevent-fix.patch
acpi-dock-send-key=value-pair-instead-of-plain-value.patch
acpi_ec_remove-fix-use-after-free.patch
acpi_battery_add-use-after-free.patch
kernel-auditscc-fix-an-off-by-one.patch
document-linux-memory-policy-v3.patch
futex_unlock_pi-hurts-my-brain-and-may-cause.patch
block-hide-the-contents-of-linux-bioh-if-config_block=n.patch
cdc-acm-fix-sysfs-attribute-registration-bug.patch
rtc-periodic-irq-fix.patch
at91-include-atmel_lcdch-in-at91sam92613_devicesc.patch
fix-local_irq_-macro-definition-thinkos-for-the-trace_irqflags_support-case.patch
calgary-fix-mis-handled-pci-topology.patch
several of which are x86-related. Please consider...
prev parent reply other threads:[~2007-08-04 5:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-02 13:39 [PATCH x86-64] Calgary - Fix mis-handled PCI topology Muli Ben-Yehuda
2007-08-04 5:25 ` Andrew Morton [this message]
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=20070803222510.fe3156cf.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ak@suse.de \
--cc=bernarde@br.ibm.com \
--cc=jdmason@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=muli@il.ibm.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