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

PCI: Disable all BAR sizing for devices with non-compliant BARs

2016-08-22T21:37:11Z

commit ad67b437f187ea818b2860524d10f878fadfdd99 upstream. b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with the PCI spec. But it didn't do anything for expansion ROM BARs, so we still try to size them, resulting in warnings like this on Broadwell-EP: pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref] Move the non-compliant BAR check from __pci_read_base() up to pci_read_bases() so it applies to the expansion ROM BAR as well as to BARs 0-5. Note that direct callers of __pci_read_base(), like sriov_init(), will now bypass this check. We haven't had reports of devices with broken SR-IOV BARs yet. [bhelgaas: changelog] Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs") Signed-off-by: Prarit Bhargava Signed-off-by: Bjorn Helgaas CC: Thomas Gleixner CC: Ingo Molnar CC: "H. Peter Anvin" CC: Andi Kleen Signed-off-by: Ben Hutchings

PCI: Disable IO/MEM decoding for devices with non-compliant BARs

2016-04-30T22:05:15Z

commit b84106b4e2290c081cdab521fa832596cdfea246 upstream. The PCI config header (first 64 bytes of each device's config space) is defined by the PCI spec so generic software can identify the device and manage its usage of I/O, memory, and IRQ resources. Some non-spec-compliant devices put registers other than BARs where the BARs should be. When the PCI core sizes these "BARs", the reads and writes it does may have unwanted side effects, and the "BAR" may appear to describe non-sensical address space. Add a flag bit to mark non-compliant devices so we don't touch their BARs. Turn off IO/MEM decoding to prevent the devices from consuming address space, since we can't read the BARs to find out what that address space would be. Signed-off-by: Bjorn Helgaas Tested-by: Andi Kleen [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

PCI: Restore detection of read-only BARs

2015-02-20T00:49:24Z

commit 36e8164882ca6d3c41cb91e6f09a3ed236841f80 upstream. Commit 6ac665c63dca ("PCI: rewrite PCI BAR reading code") masked off low-order bits from 'l', but not from 'sz'. Both are passed to pci_size(), which compares 'base == maxbase' to check for read-only BARs. The masking of 'l' means that comparison will never be 'true', so the check for read-only BARs no longer works. Resolve this by also masking off the low-order bits of 'sz' before passing it into pci_size() as 'maxbase'. With this change, pci_size() will once again catch the problems that have been encountered to date: - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is disabled, this BAR is read-only and read as 0x00000008 [1] - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1] - Intel Sandy Bridge - Thermal Management Controller [8086:0103]; BAR 0 returning 0xfed98004 [2] - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0]; Bar 0 returning 0x00001a [3] Link: [1] https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9 ("PCI: probing read-only BARs" (pre-git)) Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331 Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991 Reported-by: William Unruh Reported-by: Martin Lucina Signed-off-by: Myron Stowe Signed-off-by: Bjorn Helgaas CC: Matthew Wilcox Signed-off-by: Ben Hutchings

PCI: Check P2P bridge for invalid secondary/subordinate range

2012-10-17T02:48:34Z

commit 1965f66e7db08d1ebccd24a59043eba826cc1ce8 upstream. For bridges with "secondary > subordinate", i.e., invalid bus number apertures, we don't enumerate anything behind the bridge unless the user specified "pci=assign-busses". This patch makes us automatically try to reassign the downstream bus numbers in this case (just for that bridge, not for all bridges as "pci=assign-busses" does). We don't discover all the devices on the Intel DP43BF motherboard without this change (or "pci=assign-busses") because its BIOS configures a bridge as: pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode) [bhelgaas: changelog, change message to dev_info] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18412 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=625754 Reported-by: Brian C. Huffman Reported-by: VL Tested-by: VL Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings

PCI: workaround hard-wired bus number V2

2012-03-01T00:30:51Z

commit 71f6bd4a23130cd2f4b036010c5790b1295290b9 upstream. Fixes PCI device detection on IBM xSeries IBM 3850 M2 / x3950 M2 when using ACPI resources (_CRS). This is default, a manual workaround (without this patch) would be pci=nocrs boot param. V2: Add dev_warn if the workaround is hit. This should reveal how common such setups are (via google) and point to possible problems if things are still not working as expected. -> Suggested by Jan Beulich. Tested-by: garyhade@us.ibm.com Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

PCI: Clean-up MPS debug output

2011-10-27T19:45:44Z

Clean-up MPS debug output to make it a single line and aligned, thus making it more readable for a large number of buses and devices in a single system. Suggested by Benjamin Herrenschmidt Signed-off-by: Jon Mason Signed-off-by: Jesse Barnes

PCI: enable MPS "performance" setting to properly handle bridge MPS

2011-10-27T19:45:43Z

Rework the "performance" MPS option to configure the device MPS with the smaller of the device MPSS or the bridge MPS (which is assumed to be properly configured at this point to the largest allowable MPS based on its parent bus). Also, rework the MRRS setting to report an inability to set the MRRS to a valid setting. Signed-off-by: Jon Mason Acked-by: Benjamin Herrenschmidt Signed-off-by: Jesse Barnes

PCI: Disable MPS configuration by default

2011-10-04T16:52:28Z

Add the ability to disable PCI-E MPS turning and using the BIOS configured MPS defaults. Due to the number of issues recently discovered on some x86 chipsets, make this the default behavior. Also, add the option for peer to peer DMA MPS configuration. Peer to peer DMA is outside the scope of this patch, but MPS configuration could prevent it from working by having the MPS on one root port different than the MPS on another. To work around this, simply make the system wide MPS the smallest possible value (128B). Signed-off-by: Jon Mason Acked-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds

pci: Don't crash when reading mpss from root complex

2011-09-13T23:08:31Z

In pcie_find_smpss(), we have the following statement: if (dev->is_hotplug_bridge && (!list_is_singular(&dev->bus->devices) || dev->bus->self->pcie_type != PCI_EXP_TYPE_ROOT_PORT)) The problem is that at least on my machine, this gets called for the root complex (virtual P2P bridge), and dev->bus->self is NULL since the parent bus for this is not itself anchor to a PCI device. This adds the necessary NULL check. Signed-off-by: Benjamin Herrenschmidt Acked-by: Jon Mason Signed-off-by: Linus Torvalds

PCI: Remove MRRS modification from MPS setting code

2011-09-10T02:49:58Z

Modifying the Maximum Read Request Size to 0 (value of 128Bytes) has massive negative ramifications on some devices. Without knowing which devices have this issue, do not modify from the default value when walking the PCI-E bus in pcie_bus_safe mode. Also, make pcie_bus_safe the default procedure. Tested-by: Sven Schnelle Tested-by: Simon Kirby Tested-by: Stephen M. Cameron Reported-and-tested-by: Eric Dumazet Reported-and-tested-by: Niels Ole Salscheider References: https://bugzilla.kernel.org/show_bug.cgi?id=42162 Signed-off-by: Jon Mason Acked-by: Jesse Barnes Signed-off-by: Linus Torvalds