From: <gregkh@linuxfoundation.org>
To: bhelgaas@google.com, gregkh@linuxfoundation.org, vecu.bosseur@gmail.com
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "PCI: Don't attempt to claim shadow copies of ROM" has been added to the 4.8-stable tree
Date: Tue, 15 Nov 2016 20:10:06 +0100 [thread overview]
Message-ID: <14792370061331@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
PCI: Don't attempt to claim shadow copies of ROM
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
pci-don-t-attempt-to-claim-shadow-copies-of-rom.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 16d917b130d782b94fa02afc7bdf0d4aae689da4 Mon Sep 17 00:00:00 2001
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Tue, 8 Nov 2016 14:25:24 -0600
Subject: PCI: Don't attempt to claim shadow copies of ROM
From: Bjorn Helgaas <bhelgaas@google.com>
commit 16d917b130d782b94fa02afc7bdf0d4aae689da4 upstream.
If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM
and the device never sees accesses to it and doesn't respond to it. We
don't have to route the shadow range to the PCI device, and the device
doesn't have to claim the range.
Previously we treated the shadow copy as though it were the ROM BAR, and we
failed to claim it because the region wasn't routed to the device:
pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
pci_bus 0000:01: Allocating resources
pci 0000:01:00.0: can't claim BAR 6 [mem 0x000c0000-0x000dffff]: no compatible bridge window
The failure path of pcibios_allocate_dev_rom_resource() cleared out the
resource start address, which also caused the following ioremap() warning:
WARNING: CPU: 0 PID: 116 at /build/linux-akdJXO/linux-4.8.0/arch/x86/mm/ioremap.c:121 __ioremap_caller+0x1ec/0x370
ioremap on RAM at 0x0000000000000000 - 0x000000000001ffff
Handle an option ROM shadow copy as RAM, without trying to insert it into
the iomem resource tree.
This fixes a regression caused by 0c0e0736acad ("PCI: Set ROM shadow
location in arch code, not in PCI core"), which appeared in v4.6. The
regression causes video device initialization to fail. This was reported
on AMD Turks, but it likely affects others as well.
Fixes: 0c0e0736acad ("PCI: Set ROM shadow location in arch code, not in PCI core")
Reported-and-tested-by: Vecu Bosseur <vecu.bosseur@gmail.com>
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627496
Link: https://bugzilla.kernel.org/show_bug.cgi?id=175391
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1352272
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/setup-res.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -121,6 +121,14 @@ int pci_claim_resource(struct pci_dev *d
return -EINVAL;
}
+ /*
+ * If we have a shadow copy in RAM, the PCI device doesn't respond
+ * to the shadow range, so we don't need to claim it, and upstream
+ * bridges don't need to route the range to the device.
+ */
+ if (res->flags & IORESOURCE_ROM_SHADOW)
+ return 0;
+
root = pci_find_parent_resource(dev, res);
if (!root) {
dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge window\n",
Patches currently in stable-queue which might be from bhelgaas@google.com are
queue-4.8/pci-don-t-attempt-to-claim-shadow-copies-of-rom.patch
reply other threads:[~2016-11-15 19:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=14792370061331@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bhelgaas@google.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=vecu.bosseur@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 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.