From: <gregkh@linuxfoundation.org>
To: bhelgaas@google.com, gregkh@linuxfoundation.org,
lorenzo.pieralisi@arm.com, yinghai@kernel.org
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "PCI: Clear IORESOURCE_UNSET when clipping a bridge window" has been added to the 4.2-stable tree
Date: Sat, 17 Oct 2015 12:37:44 -0700 [thread overview]
Message-ID: <14451106644111@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
PCI: Clear IORESOURCE_UNSET when clipping a bridge window
to the 4.2-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-clear-ioresource_unset-when-clipping-a-bridge-window.patch
and it can be found in the queue-4.2 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 b838b39e930aa1cfd099ea82ac40ed6d6413af26 Mon Sep 17 00:00:00 2001
From: Bjorn Helgaas <bhelgaas@google.com>
Date: Tue, 22 Sep 2015 17:03:54 -0500
Subject: PCI: Clear IORESOURCE_UNSET when clipping a bridge window
From: Bjorn Helgaas <bhelgaas@google.com>
commit b838b39e930aa1cfd099ea82ac40ed6d6413af26 upstream.
c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") sets IORESOURCE_UNSET
if we fail to claim a resource. If we tried to claim a bridge window,
failed, clipped the window, and tried to claim the clipped window, we
failed again because of IORESOURCE_UNSET:
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff window]
pci 0000:00:01.0: can't claim BAR 15 [mem 0xbdf00000-0xddefffff 64bit pref]: no compatible bridge window
pci 0000:00:01.0: [mem size 0x20000000 64bit pref] clipped to [mem size 0x1df00000 64bit pref]
pci 0000:00:01.0: bridge window [mem size 0x1df00000 64bit pref]
pci 0000:00:01.0: can't claim BAR 15 [mem size 0x1df00000 64bit pref]: no address assigned
The 00:01.0 window started as [mem 0xbdf00000-0xddefffff 64bit pref]. That
starts before the host bridge window [mem 0xc0000000-0xffffffff window], so
we clipped the 00:01.0 window to [mem 0xc0000000-0xddefffff 64bit pref].
But we left it marked IORESOURCE_UNSET, so the second claim failed when it
should have succeeded.
This means downstream devices will also fail for lack of resources, e.g.,
in the bugzilla below,
radeon 0000:01:00.0: Fatal error during GPU init
Clear IORESOURCE_UNSET when we clip a bridge window. Also clear
IORESOURCE_UNSET in our copy of the unclipped window so we can see exactly
what the original window was and how it now fits inside the upstream
window.
Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491#c47
Based-on-patch-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Based-on-patch-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/bus.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -256,6 +256,8 @@ bool pci_bus_clip_resource(struct pci_de
res->start = start;
res->end = end;
+ res->flags &= ~IORESOURCE_UNSET;
+ orig_res.flags &= ~IORESOURCE_UNSET;
dev_printk(KERN_DEBUG, &dev->dev, "%pR clipped to %pR\n",
&orig_res, res);
Patches currently in stable-queue which might be from bhelgaas@google.com are
queue-4.2/pci-clear-ioresource_unset-when-clipping-a-bridge-window.patch
queue-4.2/x86-pci-intel_mid_pci-work-around-for-irq0-assignment.patch
reply other threads:[~2015-10-17 19:37 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=14451106644111@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bhelgaas@google.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=yinghai@kernel.org \
/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.