kernel.git/drivers/pci/probe.c, branch linux-3.15.y

Merge branch 'pci/resource' into next

2014-03-19T21:11:19Z

* pci/resource: (26 commits) Revert "[PATCH] Insert GART region into resource map" PCI: Log IDE resource quirk in dmesg PCI: Change pci_bus_alloc_resource() type_mask to unsigned long PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region() resources: Set type in __request_region() PCI: Don't check resource_size() in pci_bus_alloc_resource() s390/PCI: Use generic pci_enable_resources() tile PCI RC: Use default pcibios_enable_device() sparc/PCI: Use default pcibios_enable_device() (Leon only) sh/PCI: Use default pcibios_enable_device() microblaze/PCI: Use default pcibios_enable_device() alpha/PCI: Use default pcibios_enable_device() PCI: Add "weak" generic pcibios_enable_device() implementation PCI: Don't enable decoding if BAR hasn't been assigned an address PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit PCI: Don't try to claim IORESOURCE_UNSET resources PCI: Check IORESOURCE_UNSET before updating BAR PCI: Don't clear IORESOURCE_UNSET when updating BAR PCI: Mark resources as IORESOURCE_UNSET if we can't assign them PCI: Remove pci_find_parent_resource() use for allocation ...

PCI: Log IDE resource quirk in dmesg

2014-03-19T21:00:17Z

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

PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit

2014-02-27T17:43:33Z

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

PCI: Don't scan random busses in pci_scan_bridge()

2014-02-11T22:21:08Z

When assigning a new bus number in pci_scan_bridge we check whether max+1 is free by calling pci_find_bus. If it does already exist then we assume that we are rescanning and that this is the right bus to scan. This is fragile. If max+1 lies outside of bus->busn_res.end then we will rescan some random bus from somewhere else in the hierachy. This patch checks for this case and prints a warning. [bhelgaas: add parent/child bus number info to dev_warn()] Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas

PCI: Check for child busses which use more bus numbers than allocated

2014-02-11T22:16:09Z

pci_scan_child_bus can (potentially) return a bus number higher than the subordinate value of the child bus. Possible reasons are that bus numbers are reserved for SR-IOV or for CardBus (SR-IOV is done without checks and the CardBus checks are sketchy at best). We clamp the returned value to the actual subordinate value and print a warning if too many bus numbers are reserved. [bhelgaas: whitespace] Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas

PCI: Remove pci_fixup_parent_subordinate_busnr()

2014-02-11T22:16:09Z

The function has no effect. If pcibios_assign_all_busses() is not set then the function does nothing. If it is set then in pci_scan_bridge we are always in the branch where we assign the bus numbers ourselves and the subordinate values of all parent busses will be set to 0xff since that is what they inherited from their parent bus and ultimately from the root bus. Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas

PCI: Make sure bus number resources stay within their parents bounds

2014-02-11T00:12:45Z

Right now we use 0xff for busn_res.end when probing and later reduce it to the value that is actually used. This does not work if a parent bridge has already a lower subordinate value. For example during hotplug of a new bridge below an already-configured bridge the following message is printed from pci_bus_insert_busn_res(): pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-9b] (conflicts with (null) [bus 05-9b]) This patch clamps the bus range to that of the parent and also ensures that we do not exceed the parents range when assigning the final subordinate value. We also check that busses configured by the firmware fit into their parents bounds. [bhelgaas: reword dev_warn() and fix printk format warning] Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas

PCI: Use request_resource_conflict() instead of insert_ for bus numbers

2014-02-11T00:12:23Z

If a conflict happens during insert_resource_conflict() and all conflicts fit within the newly inserted resource then they will become children of the new resource. This is almost certainly not what we want for bus numbers. Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas

PCI: Assign CardBus bus number only during the second pass

2014-02-11T00:12:06Z

Right now the CardBus code in pci_scan_bridge() is executed during both passes. Since we always allocate the bus number ourselves it makes sense to put it into the second pass. Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas

PCI: Clarify the "scan anyway" comment in pci_scan_bridge()

2014-02-11T00:11:15Z

Initially when we encountered a bus that was already present we skipped it. Since 74710ded8e16 'PCI: always scan child buses' we continue scanning in order to allow user triggered rescans of already existing busses. The old comment suggested that the reason for continuing the scan is a bug in the i450NX chipset. This is not the case. Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas