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

PCI: Init PCIe feature bits for managed host bridge alloc

2019-05-25T16:16:43Z

commit 6302bf3ef78dd210b5ff4a922afcb7d8eff8a211 upstream. Two functions allocate a host bridge: devm_pci_alloc_host_bridge() and pci_alloc_host_bridge(). At the moment, only the unmanaged one initializes the PCIe feature bits, which prevents from using features such as hotplug or AER on some systems, when booting with device tree. Make the initialization code common. Fixes: 02bfeb484230 ("PCI/portdrv: Simplify PCIe feature permission checking") Signed-off-by: Jean-Philippe Brucker Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v4.17+ Signed-off-by: Greg Kroah-Hartman

PCI/LINK: Deduplicate bandwidth reports for multi-function devices

2019-03-25T22:59:07Z

If a multi-function device's bandwidth is already limited when it is enumerated, a message is logged only for function 0. By contrast, when downtraining occurs after enumeration, a message is logged for all functions. That's because the former uses pcie_report_downtraining(), whereas the latter uses __pcie_print_link_status() (which doesn't filter functions != 0). I am seeing this happen on a MacBookPro9,1 with a GPU (function 0) and an integrated HDA controller (function 1). Avoid this incongruence by calling pcie_report_downtraining() in both cases. Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Reviewed-by: Alexandru Gagniuc

Merge branch 'pci/enumeration'

2019-03-06T21:30:11Z

- Probe bridge window attributes only once at enumeration-time to fix device accesses during rescan (Bjorn Helgaas) - Return BAR size (not "size -1 ") from pci_size() to simplify code (Du Changbin) - Use config header type (not class code) identify bridges more reliably (Honghui Zhang) - Work around Intel Denverton incorrect Trace Hub BAR size reporting (Alexander Shishkin) * pci/enumeration: x86/PCI: Fixup RTIT_BAR of Intel Denverton Trace Hub PCI: Rely on config space header type, not class code PCI: Make pci_size() return real BAR size PCI: Probe bridge window attributes once at enumeration-time

Merge branch 'pci/aspm'

2019-03-06T21:30:09Z

- Use Latency Tolerance Reporting if already enabled by platform (Bjorn Helgaas) - Save/restore LTR info for suspend/resume (Bjorn Helgaas) * pci/aspm: PCI/ASPM: Save LTR Capability for suspend/resume PCI/ASPM: Use LTR if already enabled by platform

PCI/ASPM: Use LTR if already enabled by platform

2019-02-09T15:21:03Z

RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro 7140 table stopped working after wakeup from suspend and bisected the problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"). David Ward reported the same problem on a Dell Latitude 7350. After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it"), we don't enable LTR unless the platform has granted LTR control to us. In addition, we don't notice if the platform had already enabled LTR itself. After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"), we avoid using LTR if we don't think the path to the device has LTR enabled. The combination means that if the platform itself enables LTR but declines to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469 Fixes: 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR") Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it") Reported-by: RussianNeuroMancer Reported-by: David Ward Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v4.18+

PCI: Enable SERR# forwarding for all bridges

2019-02-02T00:12:55Z

As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages will be forwarded from the secondary interface to the primary interface, if the SERR# Enable bit in the Bridge Control register is set. It seems clear that an ACPI hotplug parameter method (_HPP or _HPX) that tells us to "enable SERR in the command register" (ACPI v6.2, sec 6.2.8, 6.2.9.1) refers to PCI_COMMAND_SERR, which enables reporting of errors by the function itself. For bridges, we also interpreted that to mean we should enable PCI_BRIDGE_CTL_SERR, which enables *forwarding* of errors by the bridge. But we didn't enable PCI_BRIDGE_CTL_SERR anywhere else, which means we never enabled it for non-ACPI systems or ACPI systems that didn't supply hotplug parameters. That means errors reported below bridges were often never forwarded up to a Root Port where they could be signaled via AER. Enable PCI_BRIDGE_CTL_SERR for all bridges so we can get better error reporting for downstream devices. Signed-off-by: Bharat Kumar Gogada [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas

PCI: Rely on config space header type, not class code

2019-01-30T16:57:08Z

The PCI configuration space header type tells us whether the device is a bridge, a CardBus bridge, or a normal device, and defines the layout of the rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9). When we rely on the header format, e.g., when we're dealing with bridge windows, we should check the header type, not the class code. The class code is loosely related to the header type, but is often incorrect and the spec doesn't actually require it to be related to the header format. Suggested-by: Bjorn Helgaas Signed-off-by: Honghui Zhang [bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check] Signed-off-by: Bjorn Helgaas

PCI: Make pci_size() return real BAR size

2019-01-30T16:44:18Z

Currently, the pci_size() function actually returns 'size-1'. Make it return real size to avoid confusion. Signed-off-by: Du Changbin Signed-off-by: Bjorn Helgaas

PCI: Probe bridge window attributes once at enumeration-time

2019-01-22T18:56:35Z

pci_bridge_check_ranges() determines whether a bridge supports the optional I/O and prefetchable memory windows and sets the flag bits in the bridge resources. This *could* be done once during enumeration except that the resource allocation code completely clears the flag bits, e.g., in the pci_assign_unassigned_bridge_resources() path. The problem with pci_bridge_check_ranges() in the resource allocation path is that we may allocate resources after devices have been claimed by drivers, and pci_bridge_check_ranges() *changes* the window registers to determine whether they're writable. This may break concurrent accesses to devices behind the bridge. Add a new pci_read_bridge_windows() to determine whether a bridge supports the optional windows, call it once during enumeration, remember the results, and change pci_bridge_check_ranges() so it doesn't touch the bridge windows but sets the flag bits based on those remembered results. Link: https://lore.kernel.org/linux-pci/1506151482-113560-1-git-send-email-wangzhou1@hisilicon.com Link: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02082.html Reported-by: Yandong Xu Tested-by: Yandong Xu Signed-off-by: Bjorn Helgaas Cc: Michael S. Tsirkin Cc: Sagi Grimberg Cc: Ofer Hayut Cc: Roy Shterman Cc: Keith Busch Cc: Zhou Wang

PCI / ACPI: Identify untrusted PCI devices

2018-12-05T09:01:55Z

A malicious PCI device may use DMA to attack the system. An external Thunderbolt port is a convenient point to attach such a device. The OS may use IOMMU to defend against DMA attacks. Some BIOSes mark these externally facing root ports with this ACPI _DSD [1]: Name (_DSD, Package () { ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"), Package () { Package () {"ExternalFacingPort", 1}, Package () {"UID", 0 } } }) If we find such a root port, mark it and all its children as untrusted. The rest of the OS may use this information to enable DMA protection against malicious devices. For instance the device may be put behind an IOMMU to keep it from accessing memory outside of what the driver has allocated for it. While at it, add a comment on top of prp_guids array explaining the possible caveat resulting when these GUIDs are treated equivalent. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports Signed-off-by: Mika Westerberg Acked-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas