From 7ed37fc3289d2d7d9c33abbebc0ecc9343e17101 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:56 -0700 Subject: [PATCH 01/26] i2o: Fix I/O space allocation copy/paste error When i2o_iop_systab_set() allocates I/O port space, it assigns the base of the new I/O port region to sb->current_mem_base, not sb->current_io_base. This looks like a copy/paste error, because we do use current_io_base, but there's no other place that sets it. Signed-off-by: Bjorn Helgaas --- drivers/message/i2o/iop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/message/i2o/iop.c b/drivers/message/i2o/iop.c index a8c08f332da0..a8373d7aaef7 100644 --- a/drivers/message/i2o/iop.c +++ b/drivers/message/i2o/iop.c @@ -704,7 +704,7 @@ static int i2o_iop_systab_set(struct i2o_controller *c) NULL, NULL) >= 0) { c->io_alloc = 1; sb->current_io_size = resource_size(res); - sb->current_mem_base = res->start; + sb->current_io_base = res->start; osm_info("%s: allocated %llu bytes of PCI I/O at " "0x%016llX.\n", c->name, (unsigned long long)resource_size(res), From 5c513bd580323dbe794270c5a96b65ba22f376eb Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:57 -0700 Subject: [PATCH 02/26] i2o: Fix I/O space alignment requirement When i2o_iop_systab_set() allocates I/O port space, it specifies 1Mb alignment required. This seems unlikely, since most platforms have only 64Kb of I/O space total. I think 4Kb is a more reasonable choice, since that's the minimum alignment of a PCI-PCI bridge I/O window. My guess is that this is a copy/paste error from the memory allocation code, which specifies 1Mb alignment (which is the minimum alignment of a PCI-PCI bridge memory window). Signed-off-by: Bjorn Helgaas --- drivers/message/i2o/iop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/message/i2o/iop.c b/drivers/message/i2o/iop.c index a8373d7aaef7..68aef58bf89c 100644 --- a/drivers/message/i2o/iop.c +++ b/drivers/message/i2o/iop.c @@ -700,7 +700,7 @@ static int i2o_iop_systab_set(struct i2o_controller *c) root = pci_find_parent_resource(c->pdev, res); if (root == NULL) osm_warn("%s: Can't find parent resource!\n", c->name); - if (root && allocate_resource(root, res, sb->desired_io_size, sb->desired_io_size, sb->desired_io_size, 1 << 20, /* Unspecified, so use 1Mb and play safe */ + if (root && allocate_resource(root, res, sb->desired_io_size, sb->desired_io_size, sb->desired_io_size, 1 << 12, /* Unspecified, so use 4Kb and play safe */ NULL, NULL) >= 0) { c->io_alloc = 1; sb->current_io_size = resource_size(res); From 60f061e19311771e67a484184340e5359493f557 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:57 -0700 Subject: [PATCH 03/26] i2o: Refactor i2o_iop_systab_set() PCI space allocation Refactor the PCI space allocation in i2o_iop_systab_set(). This might improve readability slightly, but mainly it is to make the next patch simpler. No functional change. Signed-off-by: Bjorn Helgaas --- drivers/message/i2o/iop.c | 89 ++++++++++++++++++++------------------- 1 file changed, 46 insertions(+), 43 deletions(-) diff --git a/drivers/message/i2o/iop.c b/drivers/message/i2o/iop.c index 68aef58bf89c..bd971b1b88e3 100644 --- a/drivers/message/i2o/iop.c +++ b/drivers/message/i2o/iop.c @@ -652,6 +652,48 @@ static int i2o_iop_activate(struct i2o_controller *c) return i2o_hrt_get(c); }; +static void i2o_res_alloc(struct i2o_controller *c, unsigned long flags) +{ + i2o_status_block *sb = c->status_block.virt; + struct resource *root, *res = &c->mem_resource; + resource_size_t size, min, max, align; + int err; + + res->name = c->pdev->bus->name; + res->flags = flags; + res->start = 0; + res->end = 0; + osm_info("%s: requires private memory resources.\n", c->name); + root = pci_find_parent_resource(c->pdev, res); + if (root == NULL) { + osm_warn("%s: Can't find parent resource!\n", c->name); + return; + } + + if (flags & IORESOURCE_MEM) { + size = min = max = sb->desired_mem_size; + align = 1 << 20; /* unspecified, use 1Mb and play safe */ + } else { + size = min = max = sb->desired_io_size; + align = 1 << 12; /* unspecified, use 4Kb and play safe */ + } + + err = allocate_resource(root, res, size, min, max, align, NULL, NULL); + if (err < 0) + return; + + if (flags & IORESOURCE_MEM) { + c->mem_alloc = 1; + sb->current_mem_size = resource_size(res); + sb->current_mem_base = res->start; + } else if (flags & IORESOURCE_IO) { + c->io_alloc = 1; + sb->current_io_size = resource_size(res); + sb->current_io_base = res->start; + } + osm_info("%s: allocated PCI space %pR\n", c->name, res); +} + /** * i2o_iop_systab_set - Set the I2O System Table of the specified IOP * @c: I2O controller to which the system table should be send @@ -665,52 +707,13 @@ static int i2o_iop_systab_set(struct i2o_controller *c) struct i2o_message *msg; i2o_status_block *sb = c->status_block.virt; struct device *dev = &c->pdev->dev; - struct resource *root; int rc; - if (sb->current_mem_size < sb->desired_mem_size) { - struct resource *res = &c->mem_resource; - res->name = c->pdev->bus->name; - res->flags = IORESOURCE_MEM; - res->start = 0; - res->end = 0; - osm_info("%s: requires private memory resources.\n", c->name); - root = pci_find_parent_resource(c->pdev, res); - if (root == NULL) - osm_warn("%s: Can't find parent resource!\n", c->name); - if (root && allocate_resource(root, res, sb->desired_mem_size, sb->desired_mem_size, sb->desired_mem_size, 1 << 20, /* Unspecified, so use 1Mb and play safe */ - NULL, NULL) >= 0) { - c->mem_alloc = 1; - sb->current_mem_size = resource_size(res); - sb->current_mem_base = res->start; - osm_info("%s: allocated %llu bytes of PCI memory at " - "0x%016llX.\n", c->name, - (unsigned long long)resource_size(res), - (unsigned long long)res->start); - } - } + if (sb->current_mem_size < sb->desired_mem_size) + i2o_res_alloc(c, IORESOURCE_MEM); - if (sb->current_io_size < sb->desired_io_size) { - struct resource *res = &c->io_resource; - res->name = c->pdev->bus->name; - res->flags = IORESOURCE_IO; - res->start = 0; - res->end = 0; - osm_info("%s: requires private memory resources.\n", c->name); - root = pci_find_parent_resource(c->pdev, res); - if (root == NULL) - osm_warn("%s: Can't find parent resource!\n", c->name); - if (root && allocate_resource(root, res, sb->desired_io_size, sb->desired_io_size, sb->desired_io_size, 1 << 12, /* Unspecified, so use 4Kb and play safe */ - NULL, NULL) >= 0) { - c->io_alloc = 1; - sb->current_io_size = resource_size(res); - sb->current_io_base = res->start; - osm_info("%s: allocated %llu bytes of PCI I/O at " - "0x%016llX.\n", c->name, - (unsigned long long)resource_size(res), - (unsigned long long)res->start); - } - } + if (sb->current_io_size < sb->desired_io_size) + i2o_res_alloc(c, IORESOURCE_IO); msg = i2o_msg_get_wait(c, I2O_TIMEOUT_MESSAGE_GET); if (IS_ERR(msg)) From d2e074ccbf84e91819ae07b3ca838120db2c97a9 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:57 -0700 Subject: [PATCH 04/26] i2o: Use pci_bus_alloc_resource(), not allocate_resource() directly Convert i2o_res_alloc() to use pci_bus_alloc_resource() rather than pci_find_parent_resource() and allocate_resource(). We don't have a resource to start with, so pci_find_parent_resource() can't do anything useful: a bus may have several memory resources available, so there might be several possible parents. This is more likely on root buses because host bridges may have any number of apertures. I'm pretty sure this didn't work in the first place because it passed size == min == max to allocate_resource(). The min and max parameters are constraints on the *addresses* of the resource, not on its size, so I think it was impossible for allocate_resource() to succeed. Signed-off-by: Bjorn Helgaas --- drivers/message/i2o/iop.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/message/i2o/iop.c b/drivers/message/i2o/iop.c index bd971b1b88e3..92752fb5b2d3 100644 --- a/drivers/message/i2o/iop.c +++ b/drivers/message/i2o/iop.c @@ -655,8 +655,8 @@ static int i2o_iop_activate(struct i2o_controller *c) static void i2o_res_alloc(struct i2o_controller *c, unsigned long flags) { i2o_status_block *sb = c->status_block.virt; - struct resource *root, *res = &c->mem_resource; - resource_size_t size, min, max, align; + struct resource *res = &c->mem_resource; + resource_size_t size, align; int err; res->name = c->pdev->bus->name; @@ -664,21 +664,17 @@ static void i2o_res_alloc(struct i2o_controller *c, unsigned long flags) res->start = 0; res->end = 0; osm_info("%s: requires private memory resources.\n", c->name); - root = pci_find_parent_resource(c->pdev, res); - if (root == NULL) { - osm_warn("%s: Can't find parent resource!\n", c->name); - return; - } if (flags & IORESOURCE_MEM) { - size = min = max = sb->desired_mem_size; + size = sb->desired_mem_size; align = 1 << 20; /* unspecified, use 1Mb and play safe */ } else { - size = min = max = sb->desired_io_size; + size = sb->desired_io_size; align = 1 << 12; /* unspecified, use 4Kb and play safe */ } - err = allocate_resource(root, res, size, min, max, align, NULL, NULL); + err = pci_bus_alloc_resource(c->pdev->bus, res, size, align, 0, 0, + NULL, NULL); if (err < 0) return; From 5edb93b89f6cc3089ee283656555e7a9ad36a8a0 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 4 Feb 2014 19:32:28 -0800 Subject: [PATCH 05/26] resource: Add resource_contains() We have two identical copies of resource_contains() already, and more places that could use it. This moves it to ioport.h where it can be shared. resource_contains(struct resource *r1, struct resource *r2) returns true iff r1 and r2 are the same type (most callers already checked this separately) and the r1 address range completely contains r2. In addition, the new resource_contains() checks that both r1 and r2 have addresses assigned to them. If a resource is IORESOURCE_UNSET, it doesn't have a valid address and can't contain or be contained by another resource. Some callers already check this or for res->start. No functional change. Signed-off-by: Bjorn Helgaas --- drivers/pci/host-bridge.c | 8 -------- include/linux/ioport.h | 10 ++++++++++ kernel/resource.c | 8 ++------ 3 files changed, 12 insertions(+), 14 deletions(-) diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c index 06ace6248c61..47aaf22d814e 100644 --- a/drivers/pci/host-bridge.c +++ b/drivers/pci/host-bridge.c @@ -32,11 +32,6 @@ void pci_set_host_bridge_release(struct pci_host_bridge *bridge, bridge->release_data = release_data; } -static bool resource_contains(struct resource *res1, struct resource *res2) -{ - return res1->start <= res2->start && res1->end >= res2->end; -} - void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region, struct resource *res) { @@ -45,9 +40,6 @@ void pcibios_resource_to_bus(struct pci_bus *bus, struct pci_bus_region *region, resource_size_t offset = 0; list_for_each_entry(window, &bridge->windows, list) { - if (resource_type(res) != resource_type(window->res)) - continue; - if (resource_contains(window->res, res)) { offset = window->offset; break; diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 89b7c24a36e9..9fcaac8bc4f6 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -169,6 +169,16 @@ static inline unsigned long resource_type(const struct resource *res) { return res->flags & IORESOURCE_TYPE_BITS; } +/* True iff r1 completely contains r2 */ +static inline bool resource_contains(struct resource *r1, struct resource *r2) +{ + if (resource_type(r1) != resource_type(r2)) + return false; + if (r1->flags & IORESOURCE_UNSET || r2->flags & IORESOURCE_UNSET) + return false; + return r1->start <= r2->start && r1->end >= r2->end; +} + /* Convenience shorthand with allocation */ #define request_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), 0) diff --git a/kernel/resource.c b/kernel/resource.c index 3f285dce9347..a8344dda7049 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -432,11 +432,6 @@ static void resource_clip(struct resource *res, resource_size_t min, res->end = max; } -static bool resource_contains(struct resource *res1, struct resource *res2) -{ - return res1->start <= res2->start && res1->end >= res2->end; -} - /* * Find empty slot in the resource tree with the given range and * alignment constraints @@ -471,10 +466,11 @@ static int __find_resource(struct resource *root, struct resource *old, arch_remove_reservations(&tmp); /* Check for overflow after ALIGN() */ - avail = *new; avail.start = ALIGN(tmp.start, constraint->align); avail.end = tmp.end; + avail.flags = new->flags & ~IORESOURCE_UNSET; if (avail.start >= tmp.start) { + alloc.flags = avail.flags; alloc.start = constraint->alignf(constraint->alignf_data, &avail, size, constraint->align); alloc.end = alloc.start + size - 1; From d19cb803a2ff85d1b64b9628e1aec2aa76a9260b Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:56 -0700 Subject: [PATCH 06/26] vsprintf: Add support for IORESOURCE_UNSET in %pR Sometimes we have a struct resource where we know the type (MEM/IO/etc.) and the size, but we haven't assigned address space for it. The IORESOURCE_UNSET flag is a way to indicate this situation. For these "unset" resources, the start address is meaningless, so print only the size, e.g., - pci 0000:0c:00.0: reg 184: [mem 0x00000000-0x00001fff 64bit] + pci 0000:0c:00.0: reg 184: [mem size 0x2000 64bit] For %pr (printing with raw flags), we still print the address range, because %pr is mostly used for debugging anyway. Thanks to Fengguang Wu for suggesting resource_size(). Signed-off-by: Bjorn Helgaas --- include/linux/ioport.h | 2 +- lib/vsprintf.c | 13 +++++++++---- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 9fcaac8bc4f6..5e3a906cc089 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -51,7 +51,7 @@ struct resource { #define IORESOURCE_EXCLUSIVE 0x08000000 /* Userland may not map this resource */ #define IORESOURCE_DISABLED 0x10000000 -#define IORESOURCE_UNSET 0x20000000 +#define IORESOURCE_UNSET 0x20000000 /* No address assigned yet */ #define IORESOURCE_AUTO 0x40000000 #define IORESOURCE_BUSY 0x80000000 /* Driver has marked this resource busy */ diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 185b6d300ebc..5e2cf6f342f8 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -719,10 +719,15 @@ char *resource_string(char *buf, char *end, struct resource *res, specp = &mem_spec; decode = 0; } - p = number(p, pend, res->start, *specp); - if (res->start != res->end) { - *p++ = '-'; - p = number(p, pend, res->end, *specp); + if (decode && res->flags & IORESOURCE_UNSET) { + p = string(p, pend, "size ", str_spec); + p = number(p, pend, resource_size(res), *specp); + } else { + p = number(p, pend, res->start, *specp); + if (res->start != res->end) { + *p++ = '-'; + p = number(p, pend, res->end, *specp); + } } if (decode) { if (res->flags & IORESOURCE_MEM_64) From f44116ae881868ab72274df1eff48fdbde9898af Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:58 -0700 Subject: [PATCH 07/26] PCI: Remove pci_find_parent_resource() use for allocation If the resource hasn't been allocated yet, pci_find_parent_resource() is documented as returning the region "where it should be allocated from." This is impossible in general because there may be several candidates: a prefetchable BAR can be put in either a prefetchable or non-prefetchable window, a transparent bridge may have overlapping positively- and subtractively-decoded windows, and a root bus may have several windows of the same type. Allocation should be done by pci_bus_alloc_resource(), which iterates through all bus resources and looks for the best match, e.g., one with the desired prefetchability attributes, and falls back to less-desired possibilities. The only valid use of pci_find_parent_resource() is to find the parent of an already-allocated resource so we can claim it via request_resource(), and all we need for that is a bus region of the correct type that contains the resource. Note that like 8c8def26bfaa ("PCI: allow matching of prefetchable resources to non-prefetchable windows"), this depends on pci_bus_for_each_resource() iterating through positively-decoded regions before subtractively-decoded ones. We prefer not to return a subtractively-decoded region because requesting from it will likely conflict with the overlapping positively- decoded window (see Launchpad report below). Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142 Signed-off-by: Bjorn Helgaas CC: Linus Torvalds --- drivers/pci/pci.c | 39 +++++++++++++++++++++++---------------- 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 1febe90831b4..99293fa40db9 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -401,33 +401,40 @@ EXPORT_SYMBOL_GPL(pci_find_ht_capability); * @res: child resource record for which parent is sought * * For given resource region of given device, return the resource - * region of parent bus the given region is contained in or where - * it should be allocated from. + * region of parent bus the given region is contained in. */ struct resource * pci_find_parent_resource(const struct pci_dev *dev, struct resource *res) { const struct pci_bus *bus = dev->bus; + struct resource *r; int i; - struct resource *best = NULL, *r; pci_bus_for_each_resource(bus, r, i) { if (!r) continue; - if (res->start && !(res->start >= r->start && res->end <= r->end)) - continue; /* Not contained */ - if ((res->flags ^ r->flags) & (IORESOURCE_IO | IORESOURCE_MEM)) - continue; /* Wrong type */ - if (!((res->flags ^ r->flags) & IORESOURCE_PREFETCH)) - return r; /* Exact match */ - /* We can't insert a non-prefetch resource inside a prefetchable parent .. */ - if (r->flags & IORESOURCE_PREFETCH) - continue; - /* .. but we can put a prefetchable resource inside a non-prefetchable one */ - if (!best) - best = r; + if (res->start && resource_contains(r, res)) { + + /* + * If the window is prefetchable but the BAR is + * not, the allocator made a mistake. + */ + if (r->flags & IORESOURCE_PREFETCH && + !(res->flags & IORESOURCE_PREFETCH)) + return NULL; + + /* + * If we're below a transparent bridge, there may + * be both a positively-decoded aperture and a + * subtractively-decoded region that contain the BAR. + * We want the positively-decoded one, so this depends + * on pci_bus_for_each_resource() giving us those + * first. + */ + return r; + } } - return best; + return NULL; } /** From bd064f0a231af336218838474ea45a64f1672190 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:58 -0700 Subject: [PATCH 08/26] PCI: Mark resources as IORESOURCE_UNSET if we can't assign them When assigning addresses to resources, mark them with IORESOURCE_UNSET before we start and clear IORESOURCE_UNSET if assignment is successful. That means that if we print the resource during assignment, we will show the size, not a meaningless address. Also, clear IORESOURCE_UNSET if we do assign an address, so we print the address when it is valid. Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c | 2 ++ drivers/pci/quirks.c | 5 +++++ drivers/pci/rom.c | 2 ++ drivers/pci/setup-res.c | 4 ++++ 4 files changed, 13 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 99293fa40db9..dc9ce62be7aa 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4244,6 +4244,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev) "Rounding up size of resource #%d to %#llx.\n", i, (unsigned long long)size); } + r->flags |= IORESOURCE_UNSET; r->end = size - 1; r->start = 0; } @@ -4257,6 +4258,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev) r = &dev->resource[i]; if (!(r->flags & IORESOURCE_MEM)) continue; + r->flags |= IORESOURCE_UNSET; r->end = resource_size(r) - 1; r->start = 0; } diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 5cb726c193de..6e596ab77fb9 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -296,6 +296,7 @@ static void quirk_s3_64M(struct pci_dev *dev) struct resource *r = &dev->resource[0]; if ((r->start & 0x3ffffff) || r->end != r->start + 0x3ffffff) { + r->flags |= IORESOURCE_UNSET; r->start = 0; r->end = 0x3ffffff; } @@ -937,6 +938,8 @@ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_FE_GATE_700C static void quirk_dunord(struct pci_dev *dev) { struct resource *r = &dev->resource [1]; + + r->flags |= IORESOURCE_UNSET; r->start = 0; r->end = 0xffffff; } @@ -1740,6 +1743,7 @@ static void quirk_tc86c001_ide(struct pci_dev *dev) struct resource *r = &dev->resource[0]; if (r->start & 0x8) { + r->flags |= IORESOURCE_UNSET; r->start = 0; r->end = 0xf; } @@ -1769,6 +1773,7 @@ static void quirk_plx_pci9050(struct pci_dev *dev) dev_info(&dev->dev, "Re-allocating PLX PCI 9050 BAR %u to length 256 to avoid bit 7 bug\n", bar); + r->flags |= IORESOURCE_UNSET; r->start = 0; r->end = 0xff; } diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c index 5d595724e5f4..c1839450d4d6 100644 --- a/drivers/pci/rom.c +++ b/drivers/pci/rom.c @@ -197,8 +197,10 @@ void pci_unmap_rom(struct pci_dev *pdev, void __iomem *rom) void pci_cleanup_rom(struct pci_dev *pdev) { struct resource *res = &pdev->resource[PCI_ROM_RESOURCE]; + if (res->flags & IORESOURCE_ROM_COPY) { kfree((void*)(unsigned long)res->start); + res->flags |= IORESOURCE_UNSET; res->flags &= ~IORESOURCE_ROM_COPY; res->start = 0; res->end = 0; diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index 5c060b152ce6..0474b0217fdf 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -263,6 +263,7 @@ int pci_assign_resource(struct pci_dev *dev, int resno) resource_size_t align, size; int ret; + res->flags |= IORESOURCE_UNSET; align = pci_resource_alignment(dev, res); if (!align) { dev_info(&dev->dev, "BAR %d: can't assign %pR " @@ -282,6 +283,7 @@ int pci_assign_resource(struct pci_dev *dev, int resno) ret = pci_revert_fw_address(res, dev, resno, size); if (!ret) { + res->flags &= ~IORESOURCE_UNSET; res->flags &= ~IORESOURCE_STARTALIGN; dev_info(&dev->dev, "BAR %d: assigned %pR\n", resno, res); if (resno < PCI_BRIDGE_RESOURCES) @@ -297,6 +299,7 @@ int pci_reassign_resource(struct pci_dev *dev, int resno, resource_size_t addsiz resource_size_t new_size; int ret; + res->flags |= IORESOURCE_UNSET; if (!res->parent) { dev_info(&dev->dev, "BAR %d: can't reassign an unassigned resource %pR " "\n", resno, res); @@ -307,6 +310,7 @@ int pci_reassign_resource(struct pci_dev *dev, int resno, resource_size_t addsiz new_size = resource_size(res) + addsize; ret = _pci_assign_resource(dev, resno, new_size, min_align); if (!ret) { + res->flags &= ~IORESOURCE_UNSET; res->flags &= ~IORESOURCE_STARTALIGN; dev_info(&dev->dev, "BAR %d: reassigned %pR\n", resno, res); if (resno < PCI_BRIDGE_RESOURCES) From 434aafc1aefb5eb6e8c8d15284c8f929be756521 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:59 -0700 Subject: [PATCH 09/26] PCI: Don't clear IORESOURCE_UNSET when updating BAR Clear IORESOURCE_UNSET when we assign an address to a resource, not when we write the address to the BAR. Also, drop the "BAR %d: set to %pR" message; this is mostly redundant with the "BAR %d: assigned %pR" message from pci_assign_resource(). Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index 0474b0217fdf..725d5b28398c 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -101,11 +101,6 @@ void pci_update_resource(struct pci_dev *dev, int resno) if (disable) pci_write_config_word(dev, PCI_COMMAND, cmd); - - res->flags &= ~IORESOURCE_UNSET; - dev_dbg(&dev->dev, "BAR %d: set to %pR (PCI address [%#llx-%#llx])\n", - resno, res, (unsigned long long)region.start, - (unsigned long long)region.end); } int pci_claim_resource(struct pci_dev *dev, int resource) From cd8a4d3657c3f2cf9ce3780707be1debb8fea6e2 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:59 -0700 Subject: [PATCH 10/26] PCI: Check IORESOURCE_UNSET before updating BAR Check to make sure we don't update a BAR with an address we haven't assigned. If we haven't assigned an address to a resource, we shouldn't write it to a BAR. This isn't a problem for the usual path via pci_assign_resource(), which clears IORESOURCE_UNSET before calling pci_update_resource(), but paths like pci_restore_bars() can call this for resources we haven't assigned. Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index 725d5b28398c..7f7652176fc5 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -44,6 +44,9 @@ void pci_update_resource(struct pci_dev *dev, int resno) if (!res->flags) return; + if (res->flags & IORESOURCE_UNSET) + return; + /* * Ignore non-moveable resources. This might be legacy resources for * which no functional BAR register exists or another important From 29003beb7f15d3daa5a8f9afb8d007b64baa2357 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:25:59 -0700 Subject: [PATCH 11/26] PCI: Don't try to claim IORESOURCE_UNSET resources If the IORESOURCE_UNSET bit is set, it means we haven't assigned an address yet, so don't try to claim the region. Also, make the error messages more uniform and add info about which BAR is involved. Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index 7f7652176fc5..6e443135ba24 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -111,18 +111,23 @@ int pci_claim_resource(struct pci_dev *dev, int resource) struct resource *res = &dev->resource[resource]; struct resource *root, *conflict; + if (res->flags & IORESOURCE_UNSET) { + dev_info(&dev->dev, "can't claim BAR %d %pR: no address assigned\n", + resource, res); + return -EINVAL; + } + root = pci_find_parent_resource(dev, res); if (!root) { - dev_info(&dev->dev, "no compatible bridge window for %pR\n", - res); + dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge window\n", + resource, res); return -EINVAL; } conflict = request_resource_conflict(root, res); if (conflict) { - dev_info(&dev->dev, - "address space collision: %pR conflicts with %s %pR\n", - res, conflict->name, conflict); + dev_info(&dev->dev, "can't claim BAR %d %pR: address conflict with %s %pR\n", + resource, res, conflict->name, conflict); return -EBUSY; } From c83bd900aac38552b0d903588bbb084d3b26fe71 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:26:00 -0700 Subject: [PATCH 12/26] PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit If we don't support 64-bit addresses, i.e., CONFIG_PHYS_ADDR_T_64BIT is not set, we can't deal with BARs above 4GB. In this case we already pretend the BAR contained zero; this patch also sets IORESOURCE_UNSET so we can try to reallocate it later. I don't think this is exactly correct: what we care about here are *bus* addresses, not CPU addresses, so the tests of sizeof(resource_size_t) probably should be on sizeof(dma_addr_t) instead. But this is what's been in -next, so we'll fix that later. Signed-off-by: Bjorn Helgaas --- drivers/pci/probe.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 6e34498ec9f0..78335efbbb74 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -252,6 +252,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, /* Address above 32-bit boundary; disable the BAR */ pci_write_config_dword(dev, pos, 0); pci_write_config_dword(dev, pos + 4, 0); + res->flags |= IORESOURCE_UNSET; region.start = 0; region.end = sz64; bar_disabled = true; From 3cedcc3621289d41bd21c5dbe0b886d57c83a1ea Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:26:00 -0700 Subject: [PATCH 13/26] PCI: Don't enable decoding if BAR hasn't been assigned an address Don't enable memory or I/O decoding if we haven't assigned or claimed the BAR's resource. If we enable decoding for a BAR that hasn't been assigned an address, we'll likely cause bus conflicts. This declines to enable decoding for resources with IORESOURCE_UNSET. Note that drivers can use pci_enable_device_io() or pci_enable_device_mem() if they only care about specific types of BARs. In that case, we don't bother checking whether the corresponding resources are assigned or claimed. Signed-off-by: Bjorn Helgaas --- drivers/pci/setup-res.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c index 6e443135ba24..7eed671d5586 100644 --- a/drivers/pci/setup-res.c +++ b/drivers/pci/setup-res.c @@ -343,9 +343,15 @@ int pci_enable_resources(struct pci_dev *dev, int mask) (!(r->flags & IORESOURCE_ROM_ENABLE))) continue; + if (r->flags & IORESOURCE_UNSET) { + dev_err(&dev->dev, "can't enable device: BAR %d %pR not assigned\n", + i, r); + return -EINVAL; + } + if (!r->parent) { - dev_err(&dev->dev, "device not available " - "(can't reserve %pR)\n", r); + dev_err(&dev->dev, "can't enable device: BAR %d %pR not claimed\n", + i, r); return -EINVAL; } From 8a9d56097c142d0716234eb1cf7c8150c6dc1588 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:26:00 -0700 Subject: [PATCH 14/26] PCI: Add "weak" generic pcibios_enable_device() implementation Many architectures implement pcibios_enable_device() the same way, so provide a default implementation in the core. Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index dc9ce62be7aa..c3ce3d61091c 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1185,6 +1185,11 @@ int pci_load_and_free_saved_state(struct pci_dev *dev, } EXPORT_SYMBOL_GPL(pci_load_and_free_saved_state); +int __weak pcibios_enable_device(struct pci_dev *dev, int bars) +{ + return pci_enable_resources(dev, bars); +} + static int do_pci_enable_device(struct pci_dev *dev, int bars) { int err; From 3eb03bdbaeeb98331ab0582e023c2e57b42944f0 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:26:01 -0700 Subject: [PATCH 15/26] alpha/PCI: Use default pcibios_enable_device() We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas CC: linux-alpha@vger.kernel.org --- arch/alpha/kernel/pci.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c index edb4e0097b75..076c35cd6cde 100644 --- a/arch/alpha/kernel/pci.c +++ b/arch/alpha/kernel/pci.c @@ -254,12 +254,6 @@ void pcibios_fixup_bus(struct pci_bus *bus) } } -int -pcibios_enable_device(struct pci_dev *dev, int mask) -{ - return pci_enable_resources(dev, mask); -} - /* * If we set up a device for bus mastering, we need to check the latency * timer as certain firmware forgets to set it properly, as seen From cd3183ba228bf88b242cc7dca219020601df0927 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:26:01 -0700 Subject: [PATCH 16/26] microblaze/PCI: Use default pcibios_enable_device() We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas CC: Michal Simek CC: microblaze-uclinux@itee.uq.edu.au --- arch/microblaze/pci/pci-common.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c index 66804adcacf0..70996cc66aa2 100644 --- a/arch/microblaze/pci/pci-common.c +++ b/arch/microblaze/pci/pci-common.c @@ -1294,11 +1294,6 @@ void pcibios_finish_adding_to_bus(struct pci_bus *bus) } EXPORT_SYMBOL_GPL(pcibios_finish_adding_to_bus); -int pcibios_enable_device(struct pci_dev *dev, int mask) -{ - return pci_enable_resources(dev, mask); -} - static void pcibios_setup_phb_resources(struct pci_controller *hose, struct list_head *resources) { From 3a6fc2fb7eb2a4973e29c0fb0c8d0f61d5babeb0 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 11:26:02 -0700 Subject: [PATCH 17/26] sh/PCI: Use default pcibios_enable_device() We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Signed-off-by: Bjorn Helgaas CC: Paul Mundt CC: linux-sh@vger.kernel.org --- arch/sh/drivers/pci/pci.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c index 60ed3e1c4b75..1bc09ee7948f 100644 --- a/arch/sh/drivers/pci/pci.c +++ b/arch/sh/drivers/pci/pci.c @@ -186,11 +186,6 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res, return start; } -int pcibios_enable_device(struct pci_dev *dev, int mask) -{ - return pci_enable_resources(dev, mask); -} - static void __init pcibios_bus_report_status_early(struct pci_channel *hose, int top_bus, int current_bus, From f6baf35f7957aa6986e6897734a0cc4eb442cf94 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 15:18:44 -0700 Subject: [PATCH 18/26] sparc/PCI: Use default pcibios_enable_device() (Leon only) We don't need anything arch-specific in pcibios_enable_device() so drop the arch implementation and use the default generic one. Note that sparc has two pcibios_enable_device() implementations other than the one removed here. Signed-off-by: Bjorn Helgaas CC: Daniel Hellstrom start; } -int pcibios_enable_device(struct pci_dev *dev, int mask) -{ - return pci_enable_resources(dev, mask); -} - /* in/out routines taken from pcic.c * * This probably belongs here rather than ioport.c because From 05d58f6075bfab1f4ef424c6e5a3e22ecc09f015 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 16:10:25 -0700 Subject: [PATCH 19/26] tile PCI RC: Use default pcibios_enable_device() We don't need anything arch-specific in pcibios_enable_device(), so drop the arch implementation and use the default generic one. Note: pci_enable_resources() checks that r->parent is non-NULL, which basically checks that pci_claim_resource() or request_resource() has been called for each BAR. I don't see where that happens for tile, but this patch doesn't change that behavior, so if it worked before, it should still work. Signed-off-by: Bjorn Helgaas Acked-by: Chris Metcalf --- arch/tile/kernel/pci_gx.c | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c index a97a6452b812..077b7bc437e5 100644 --- a/arch/tile/kernel/pci_gx.c +++ b/arch/tile/kernel/pci_gx.c @@ -1064,18 +1064,6 @@ char *__init pcibios_setup(char *str) return str; } -/* - * Enable memory address decoding, as appropriate, for the - * device described by the 'dev' struct. - * - * This is called from the generic PCI layer, and can be called - * for bridges or endpoints. - */ -int pcibios_enable_device(struct pci_dev *dev, int mask) -{ - return pci_enable_resources(dev, mask); -} - /* * Called for each device after PCI setup is done. * We initialize the PCI device capabilities conservatively, assuming that From d75332325389a95c4ddbfa0f0cd7e5e08a54aa43 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 26 Feb 2014 15:30:24 -0700 Subject: [PATCH 20/26] s390/PCI: Use generic pci_enable_resources() The generic pci_enable_resources() does essentially the same thing as the code in the s390 version of pcibios_enable_device(). There are differences, but I don't think any of them are a problem. The generic code: - Checks everything up to PCI_NUM_RESOURCES, not PCI_BAR_COUNT (6), so we'll now check the ROM resource, IOV resources, and bridge windows. - Checks for res->flags & IORESOURCE_UNSET. The s390 code never sets IORESOURCE_UNSET, so this isn't a problem. - Checks res->parent. The s390 pcibios_add_device() calls pci_claim_resource() on all BARs (except ROM, IOV, and bridge windows) so this isn't a problem either. Signed-off-by: Bjorn Helgaas Acked-by: Sebastian Ott --- arch/s390/pci/pci.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c index 66670ff262a0..1df1d29ac81d 100644 --- a/arch/s390/pci/pci.c +++ b/arch/s390/pci/pci.c @@ -686,27 +686,13 @@ int pcibios_add_device(struct pci_dev *pdev) int pcibios_enable_device(struct pci_dev *pdev, int mask) { struct zpci_dev *zdev = get_zdev(pdev); - struct resource *res; - u16 cmd; - int i; zdev->pdev = pdev; zpci_debug_init_device(zdev); zpci_fmb_enable_device(zdev); zpci_map_resources(zdev); - pci_read_config_word(pdev, PCI_COMMAND, &cmd); - for (i = 0; i < PCI_BAR_COUNT; i++) { - res = &pdev->resource[i]; - - if (res->flags & IORESOURCE_IO) - return -EINVAL; - - if (res->flags & IORESOURCE_MEM) - cmd |= PCI_COMMAND_MEMORY; - } - pci_write_config_word(pdev, PCI_COMMAND, cmd); - return 0; + return pci_enable_resources(pdev, mask); } void pcibios_disable_device(struct pci_dev *pdev) From e20fa6609a0076def469aeb799b1c25558e70042 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 10 Mar 2014 10:46:56 -0600 Subject: [PATCH 21/26] PCI: Don't check resource_size() in pci_bus_alloc_resource() Paul reported that after f75b99d5a77d ("PCI: Enforce bus address limits in resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not set), intel-gtt complained "can't ioremap flush page - no chipset flushing". In addition, other PCI resource allocations, e.g., for bridge windows, failed. This happens because we incorrectly skip bus resources of [mem 0x00000000-0xffffffff] because we think they are of size zero. When resource_size_t is 32 bits wide, resource_size() on [mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1) overflows. Therefore, we can't use "resource_size() == 0" to decide that allocation from this resource will fail. allocate_resource() should fail anyway if it can't satisfy the address constraints, so we should just depend on that. A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid, but we do fall back to it as a default when we don't have information about host bridge apertures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation Reported-and-tested-by: Paul Bolle Signed-off-by: Bjorn Helgaas --- drivers/pci/bus.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 00660cc502c5..38901665c770 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -162,8 +162,6 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res, avail = *r; pci_clip_resource_to_region(bus, &avail, region); - if (!resource_size(&avail)) - continue; /* * "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to From 6404e88e8385638123f4b18b104430480870601a Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Fri, 7 Mar 2014 09:22:19 -0700 Subject: [PATCH 22/26] resources: Set type in __request_region() We don't set the type (I/O, memory, etc.) of resources added by __request_region(), which leads to confusing messages like this: address space collision: [io 0x1000-0x107f] conflicts with ACPI CPU throttle [??? 0x00001010-0x00001015 flags 0x80000000] Set the type of a new resource added by __request_region() (used by request_region() and request_mem_region()) to the type of its parent. This makes the resource tree internally consistent and fixes messages like the above, where the ACPI CPU throttle resource really is an I/O port region, but request_region() didn't fill in the type, so %pR didn't know how to print it. Sample dmesg showing the issue at the link below. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 Reported-by: Paul Bolle Signed-off-by: Bjorn Helgaas --- kernel/resource.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/resource.c b/kernel/resource.c index a8344dda7049..673061c06da1 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -945,8 +945,8 @@ struct resource * __request_region(struct resource *parent, res->name = name; res->start = start; res->end = start + n - 1; - res->flags = IORESOURCE_BUSY; - res->flags |= flags; + res->flags = resource_type(parent); + res->flags |= IORESOURCE_BUSY | flags; write_lock(&resource_lock); From aa11fc58dc71c27701b1f9a529a36a38d4337722 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Fri, 7 Mar 2014 13:39:01 -0700 Subject: [PATCH 23/26] PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region() When allocating space from a bus resource, i.e., from apertures leading to this bus, make sure the entire resource type matches. The previous code assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single bit set, but this is not true. IORESOURCE_TYPE_BITS is really an enumeration, and we have to check all the bits. See 72dcb1197228 ("resources: Add register address resource type"). No functional change. If we used this path for allocating IRQs, DMA channels, or bus numbers, this would fix a bug because those types are indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM. But we don't, so this shouldn't make any difference. Signed-off-by: Bjorn Helgaas --- drivers/pci/bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index 38901665c770..e3bdc88668ec 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -144,7 +144,7 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res, struct resource *r, avail; resource_size_t max; - type_mask |= IORESOURCE_IO | IORESOURCE_MEM; + type_mask |= IORESOURCE_TYPE_BITS; pci_bus_for_each_resource(bus, r, i) { if (!r) From 664c28480c90fb8541bcdd1d4b349e9436165ec7 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Fri, 7 Mar 2014 13:51:12 -0700 Subject: [PATCH 24/26] PCI: Change pci_bus_alloc_resource() type_mask to unsigned long The pci_bus_alloc_resource() "type_mask" parameter is used to compare with the "flags" member of a struct resource, so it should be the same type, namely "unsigned long". No functional change because all current IORESOURCE_* flags fit in 32 bits. Signed-off-by: Bjorn Helgaas --- drivers/pci/bus.c | 4 ++-- include/linux/pci.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c index e3bdc88668ec..fb8aed307c28 100644 --- a/drivers/pci/bus.c +++ b/drivers/pci/bus.c @@ -132,7 +132,7 @@ static void pci_clip_resource_to_region(struct pci_bus *bus, static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res, resource_size_t size, resource_size_t align, - resource_size_t min, unsigned int type_mask, + resource_size_t min, unsigned long type_mask, resource_size_t (*alignf)(void *, const struct resource *, resource_size_t, @@ -200,7 +200,7 @@ static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res, */ int pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res, resource_size_t size, resource_size_t align, - resource_size_t min, unsigned int type_mask, + resource_size_t min, unsigned long type_mask, resource_size_t (*alignf)(void *, const struct resource *, resource_size_t, diff --git a/include/linux/pci.h b/include/linux/pci.h index fb57c892b214..60ebc17fe909 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1066,7 +1066,7 @@ void pci_bus_remove_resources(struct pci_bus *bus); int __must_check pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res, resource_size_t size, resource_size_t align, resource_size_t min, - unsigned int type_mask, + unsigned long type_mask, resource_size_t (*alignf)(void *, const struct resource *, resource_size_t, From 075eb9e35578c23ee2414f87d97d2e5065aa1bc1 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Wed, 5 Mar 2014 14:07:03 -0700 Subject: [PATCH 25/26] PCI: Log IDE resource quirk in dmesg Make a note in dmesg when we overwrite legacy IDE BAR info. We previously logged something like this: pci 0000:00:1f.1: reg 0x10: [io 0x0000-0x0007] and then silently overwrote the resource. There's an example in the bugzilla below. This doesn't fix the bugzilla; it just makes what's going on more obvious. No functional change; merely adds some dev_info() calls. Link: https://bugzilla.kernel.org/show_bug.cgi?id=48451 Signed-off-by: Bjorn Helgaas --- drivers/pci/probe.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 78335efbbb74..93dad114eaef 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1126,10 +1126,10 @@ int pci_setup_device(struct pci_dev *dev) pci_read_config_word(dev, PCI_SUBSYSTEM_ID, &dev->subsystem_device); /* - * Do the ugly legacy mode stuff here rather than broken chip - * quirk code. Legacy mode ATA controllers have fixed - * addresses. These are not always echoed in BAR0-3, and - * BAR0-3 in a few cases contain junk! + * Do the ugly legacy mode stuff here rather than broken chip + * quirk code. Legacy mode ATA controllers have fixed + * addresses. These are not always echoed in BAR0-3, and + * BAR0-3 in a few cases contain junk! */ if (class == PCI_CLASS_STORAGE_IDE) { u8 progif; @@ -1140,11 +1140,15 @@ int pci_setup_device(struct pci_dev *dev) res = &dev->resource[0]; res->flags = LEGACY_IO_RESOURCE; pcibios_bus_to_resource(dev->bus, res, ®ion); + dev_info(&dev->dev, "legacy IDE quirk: reg 0x10: %pR\n", + res); region.start = 0x3F6; region.end = 0x3F6; res = &dev->resource[1]; res->flags = LEGACY_IO_RESOURCE; pcibios_bus_to_resource(dev->bus, res, ®ion); + dev_info(&dev->dev, "legacy IDE quirk: reg 0x14: %pR\n", + res); } if ((progif & 4) == 0) { region.start = 0x170; @@ -1152,11 +1156,15 @@ int pci_setup_device(struct pci_dev *dev) res = &dev->resource[2]; res->flags = LEGACY_IO_RESOURCE; pcibios_bus_to_resource(dev->bus, res, ®ion); + dev_info(&dev->dev, "legacy IDE quirk: reg 0x18: %pR\n", + res); region.start = 0x376; region.end = 0x376; res = &dev->resource[3]; res->flags = LEGACY_IO_RESOURCE; pcibios_bus_to_resource(dev->bus, res, ®ion); + dev_info(&dev->dev, "legacy IDE quirk: reg 0x1c: %pR\n", + res); } } break; From f2e6027b816df3326d3f40d6ce55539a2f381529 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 17 Mar 2014 16:32:52 -0600 Subject: [PATCH 26/26] Revert "[PATCH] Insert GART region into resource map" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This reverts commit 56dd669a138c, which makes the GART visible in /proc/iomem. This fixes a regression: e501b3d87f00 ("agp: Support 64-bit APBASE") exposed an existing problem with a conflict between the GART region and a PCI BAR region. The GART addresses are bus addresses, not CPU addresses, and therefore should not be inserted in iomem_resource. On many machines, the GART region is addressable by the CPU as well as by an AGP master, but CPU addressability is not required by the spec. On some of these machines, the GART is mapped by a PCI BAR, and in that case, the PCI core automatically inserts it into iomem_resource, just as it does for all BARs. Inserting it here means we'll have a conflict if the PCI core later tries to claim the GART region, so let's drop the insertion here. The conflict indirectly causes X failures, as reported by Jouni in the bugzilla below. We detected the conflict even before e501b3d87f00, but after it the AGP code (fix_northbridge()) uses the PCI resource (which is zeroed because of the conflict) instead of reading the BAR again. Conflicts: arch/x86_64/kernel/aperture.c Fixes: e501b3d87f00 agp: Support 64-bit APBASE Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201 Reported-and-tested-by: Jouni Mettälä Signed-off-by: Bjorn Helgaas --- arch/x86/kernel/aperture_64.c | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c index fd972a3e4cbb..9fa8aa051f54 100644 --- a/arch/x86/kernel/aperture_64.c +++ b/arch/x86/kernel/aperture_64.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include @@ -54,18 +53,6 @@ int fallback_aper_force __initdata; int fix_aperture __initdata = 1; -static struct resource gart_resource = { - .name = "GART", - .flags = IORESOURCE_MEM, -}; - -static void __init insert_aperture_resource(u32 aper_base, u32 aper_size) -{ - gart_resource.start = aper_base; - gart_resource.end = aper_base + aper_size - 1; - insert_resource(&iomem_resource, &gart_resource); -} - /* This code runs before the PCI subsystem is initialized, so just access the northbridge directly. */ @@ -96,7 +83,6 @@ static u32 __init allocate_aperture(void) memblock_reserve(addr, aper_size); printk(KERN_INFO "Mapping aperture over %d KB of RAM @ %lx\n", aper_size >> 10, addr); - insert_aperture_resource((u32)addr, aper_size); register_nosave_region(addr >> PAGE_SHIFT, (addr+aper_size) >> PAGE_SHIFT); @@ -444,12 +430,8 @@ int __init gart_iommu_hole_init(void) out: if (!fix && !fallback_aper_force) { - if (last_aper_base) { - unsigned long n = (32 * 1024 * 1024) << last_aper_order; - - insert_aperture_resource((u32)last_aper_base, n); + if (last_aper_base) return 1; - } return 0; }