path: root/CREDITS
diff options
authorBjorn Helgaas <>2015-04-21 14:57:26 -0500
committerBjorn Helgaas <>2015-04-21 15:29:39 -0500
commit9fbbda5c8e0ab9c391e4160a0eb3a06260f9f668 (patch)
treedf1d59127854425e1a7356b416c14f19a205da6e /CREDITS
parentaf539e985b3fbe3b602313f317506a2a9e73f5bf (diff)
ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows
Prior to c770cb4cb505 ("PCI: Mark invalid BARs as unassigned"), if we tried to claim a PCI BAR but could not find an upstream bridge window that matched it, we complained but still allowed the device to be enabled. c770cb4cb505 broke devices that previously worked (mptsas and igb in the case Tony reported, but it could be any devices) because it marks those BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and return failure: igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned igb: probe of 0000:81:00.0 failed with error -22 The underlying cause is an ACPI Address Space Descriptor for a PCI host bridge window that is marked as "consumer". This is a firmware defect: resources that are produced on the downstream side of a bridge should be marked "producer". But rejecting these BARs that we previously allowed is a functionality regression, and firmware has not used the producer/consumer bit consistently, so we can't rely on it anyway. Stop checking the producer/consumer bit, and assume all bridge Address Space Descriptors are for bridge windows. Note that this change does not affect I/O Port or Fixed Location I/O Port Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config access range. That range is a "consumer" range and should not be treated as a window. Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") Link: Reported-and-tested-by: Tony Luck <> Signed-off-by: Bjorn Helgaas <> Acked-by: Rafael J. Wysocki <>
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud