3.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guo Chao <y...@linux.vnet.ibm.com>
commit c33377082dd9ede1e998f7ce416077e4b1c2276c upstream.
If we have space assigned to a resource, we try to expand the resource
(e.g., to accommodate SR-IOV resources), and the expansion attempt fails,
we should keep the original assignment.
After bd064f0a231a ("PCI: Mark resources as IORESOURCE_UNSET if we can't
assign them"), we left the resource marked IORESOURCE_UNSET when the
expansion failed, even if it had originally been set. That caused errors
like this:
pci 0003:00:00.0: can't enable device: BAR 15 [mem size 0x0c000000 64bit
pref] not assigned
pci 0003:00:00.0: Error enabling bridge (-22), continuing
Fix this by restoring the original flags when reassignment fails.
[bhelgaas: reworked to simplify, changelog]
Fixes: bd064f0a231a ("PCI: Mark resources as IORESOURCE_UNSET if we can't
assign them")
Signed-off-by: Guo Chao <y...@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/pci/setup-res.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -320,9 +320,11 @@ int pci_reassign_resource(struct pci_dev
resource_size_t min_align)
{
struct resource *res = dev->resource + resno;
+ unsigned long flags;
resource_size_t new_size;
int ret;
+ flags = res->flags;
res->flags |= IORESOURCE_UNSET;
if (!res->parent) {
dev_info(&dev->dev, "BAR %d: can't reassign an unassigned
resource %pR\n",
@@ -339,7 +341,12 @@ int pci_reassign_resource(struct pci_dev
dev_info(&dev->dev, "BAR %d: reassigned %pR\n", resno, res);
if (resno < PCI_BRIDGE_RESOURCES)
pci_update_resource(dev, resno);
+ } else {
+ res->flags = flags;
+ dev_info(&dev->dev, "BAR %d: %pR (failed to expand by %#llx)\n",
+ resno, res, (unsigned long long) addsize);
}
+
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
