kernel.git/drivers/pci/bus.c, branch linux-6.4.y

PCI: move OF status = "disabled" detection to dev->match_driver

2023-08-16T16:32:26Z

commit 1a8c251cff2052b60009a070173308322e9600d3 upstream. The blamed commit has broken probing on arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi when &enetc_port0 (PCI function 0) has status = "disabled". Background: pci_scan_slot() has logic to say that if the function 0 of a device is absent, the entire device is absent and we can skip the other functions entirely. Traditionally, this has meant that pci_bus_read_dev_vendor_id() returns an error code for that function. However, since the blamed commit, there is an extra confounding condition: function 0 of the device exists and has a valid vendor id, but it is disabled in the device tree. In that case, pci_scan_slot() would incorrectly skip the entire device instead of just that function. In the case of NXP LS1028A, status = "disabled" does not mean that the PCI function's config space is not available for reading. It is, but the Ethernet port is just not functionally useful with a particular SerDes protocol configuration (0x9999) due to pinmuxing constraints of the Soc. So, pci_scan_slot() skips all other functions on the ENETC ECAM (enetc_port1, enetc_port2, enetc_mdio_pf3 etc) when just enetc_port0 had to not be probed. There is an additional regression introduced by the change, caused by its fundamental premise. The enetc driver needs to run code for all PCI functions, regardless of whether they're enabled or not in the device tree. That is no longer possible if the driver's probe function is no longer called. But Rob recommends that we move the of_device_is_available() detection to dev->match_driver, and this makes the PCI fixups still run on all functions, while just probing drivers for those functions that are enabled. So, a separate change in the enetc driver will have to move the workarounds to a PCI fixup. Fixes: 6fffbc7ae137 ("PCI: Honor firmware's device disabled status") Link: https://lore.kernel.org/netdev/CAL_JsqLsVYiPLx2kcHkDQ4t=hQVCR7NHziDwi9cCFUFhx48Qow@mail.gmail.com/ Suggested-by: Rob Herring Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Merge tag 'pci-v6.4-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci

2023-04-27T17:45:30Z

Pull pci updates from Bjorn Helgaas: "Resource management: - Add pci_dev_for_each_resource() and pci_bus_for_each_resource() iterators PCIe native device hotplug: - Fix AB-BA deadlock between reset_lock and device_lock Power management: - Wait longer for devices to become ready after resume (as we do for reset) to accommodate Intel Titan Ridge xHCI devices - Extend D3hot delay for NVIDIA HDA controllers to avoid unrecoverable devices after a bus reset Error handling: - Clear PCIe Device Status after EDR since generic error recovery now only clears it when AER is native ASPM: - Work around Chromebook firmware defect that clobbers Capability list (including ASPM L1 PM Substates Cap) when returning from D3cold to D0 Freescale i.MX6 PCIe controller driver: - Install imprecise external abort handler only when DT indicates PCIe support Freescale Layerscape PCIe controller driver: - Add ls1028a endpoint mode support Qualcomm PCIe controller driver: - Add SM8550 DT binding and driver support - Add SDX55 DT binding and driver support - Use bulk APIs for clocks of IP 1.0.0, 2.3.2, 2.3.3 - Use bulk APIs for reset of IP 2.1.0, 2.3.3, 2.4.0 - Add DT "mhi" register region for supported SoCs - Expose link transition counts via debugfs to help debug low power issues - Support system suspend and resume; reduce interconnect bandwidth and turn off clock and PHY if there are no active devices - Enable async probe by default to reduce boot time Miscellaneous: - Sort controller Kconfig entries by vendor" * tag 'pci-v6.4-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (56 commits) PCI: xilinx: Drop obsolete dependency on COMPILE_TEST PCI: mobiveil: Sort Kconfig entries by vendor PCI: dwc: Sort Kconfig entries by vendor PCI: Sort controller Kconfig entries by vendor PCI: Use consistent controller Kconfig menu entry language PCI: xilinx-nwl: Add 'Xilinx' to Kconfig prompt PCI: hv: Add 'Microsoft' to Kconfig prompt PCI: meson: Add 'Amlogic' to Kconfig prompt PCI: Use of_property_present() for testing DT property presence PCI/PM: Extend D3hot delay for NVIDIA HDA controllers dt-bindings: PCI: qcom: Document msi-map and msi-map-mask properties PCI: qcom: Add SM8550 PCIe support dt-bindings: PCI: qcom: Add SM8550 compatible PCI: qcom: Add support for SDX55 SoC dt-bindings: PCI: qcom-ep: Fix the unit address used in example dt-bindings: PCI: qcom: Add SDX55 SoC dt-bindings: PCI: qcom: Update maintainers entry PCI: qcom: Enable async probe by default PCI: qcom: Add support for system suspend and resume PCI/PM: Drop pci_bridge_wait_for_secondary_bus() timeout parameter ...

PCI: Make pci_bus_for_each_resource() index optional

2023-04-05T20:10:09Z

Refactor pci_bus_for_each_resource() in the same way as pci_dev_for_each_resource(). This allows the index to be hidden inside the implementation so the caller can omit it when it's not used otherwise. No functional changes intended. Link: https://lore.kernel.org/r/20230330162434.35055-6-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński Reviewed-by: Philippe Mathieu-Daudé

PCI: s390: Fix use-after-free of PCI resources with per-function hotplug

2023-03-13T08:15:11Z

On s390 PCI functions may be hotplugged individually even when they belong to a multi-function device. In particular on an SR-IOV device VFs may be removed and later re-added. In commit a50297cf8235 ("s390/pci: separate zbus creation from scanning") it was missed however that struct pci_bus and struct zpci_bus's resource list retained a reference to the PCI functions MMIO resources even though those resources are released and freed on hot-unplug. These stale resources may subsequently be claimed when the PCI function re-appears resulting in use-after-free. One idea of fixing this use-after-free in s390 specific code that was investigated was to simply keep resources around from the moment a PCI function first appeared until the whole virtual PCI bus created for a multi-function device disappears. The problem with this however is that due to the requirement of artificial MMIO addreesses (address cookies) extra logic is then needed to keep the address cookies compatible on re-plug. At the same time the MMIO resources semantically belong to the PCI function so tying their lifecycle to the function seems more logical. Instead a simpler approach is to remove the resources of an individually hot-unplugged PCI function from the PCI bus's resource list while keeping the resources of other PCI functions on the PCI bus untouched. This is done by introducing pci_bus_remove_resource() to remove an individual resource. Similarly the resource also needs to be removed from the struct zpci_bus's resource list. It turns out however, that there is really no need to add the MMIO resources to the struct zpci_bus's resource list at all and instead we can simply use the zpci_bar_struct's resource pointer directly. Fixes: a50297cf8235 ("s390/pci: separate zbus creation from scanning") Signed-off-by: Niklas Schnelle Reviewed-by: Matthew Rosato Acked-by: Bjorn Helgaas Link: https://lore.kernel.org/r/20230306151014.60913-2-schnelle@linux.ibm.com Signed-off-by: Vasily Gorbik

PCI: Skip allocate_resource() if too little space available

2022-12-10T16:31:47Z

pci_bus_alloc_from_region() allocates MMIO space by iterating through all the resources available on the bus. The available resource might be reduced if the caller requires 32-bit space or we're avoiding BIOS or E820 areas. Don't bother calling allocate_resource() if we need more space than is available in this resource. This prevents some pointless and annoying messages about avoided areas. Link: https://lore.kernel.org/r/20221208190341.1560157-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas Acked-by: Hans de Goede

PCI: Add device even if driver attach failed

2020-07-07T22:33:41Z

device_attach() returning failure indicates a driver error while trying to probe the device. In such a scenario, the PCI device should still be added in the system and be visible to the user. When device_attach() fails, merely warn about it and keep the PCI device in the system. This partially reverts ab1a187bba5c ("PCI: Check device_attach() return value always"). Link: https://lore.kernel.org/r/20200706233240.3245512-1-rajatja@google.com Signed-off-by: Rajat Jain Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org # v4.6+

PCI: Unexport pci_bus_get() and pci_bus_put()

2019-07-23T23:32:49Z

pci_bus_get() and pci_bus_put() are not used by a loadable kernel module and do not need to be exported. These were exported by fe830ef62ac6 ("PCI: Introduce pci_bus_{get|put}() to manage PCI bus reference count"), but there are no loadable modules in the tree that use them. Link: https://lore.kernel.org/r/20190717182353.45557-1-skunberg.kelsey@gmail.com Signed-off-by: Kelsey Skunberg Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman

PCI: Replace dev_printk(KERN_DEBUG) with dev_info(), etc

2019-05-09T12:49:58Z

Replace dev_printk(KERN_DEBUG) with dev_info(), etc to be more consistent with other logging and avoid checkpatch warnings. The KERN_DEBUG messages could be converted to dev_dbg(), but that depends on CONFIG_DYNAMIC_DEBUG and DEBUG, and we want most of these messages to *always* be in the dmesg log. Link: https://lore.kernel.org/lkml/1555733240-19875-1-git-send-email-mohankumar718@gmail.com Signed-off-by: Mohan Kumar [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas

PCI: Replace printk(KERN_INFO) with pr_info(), etc

2019-05-09T12:49:54Z

Replace printk() with pr_*() to be more consistent with other logging and avoid checkpatch warnings. Link: https://lore.kernel.org/lkml/1555733026-19609-1-git-send-email-mohankumar718@gmail.com Link: https://lore.kernel.org/lkml/1555733130-19804-1-git-send-email-mohankumar718@gmail.com Signed-off-by: Mohan Kumar [bhelgaas: squash in similar changes from second patch in series] Signed-off-by: Bjorn Helgaas

PCI: Fix is_added/is_busmaster race condition

2018-07-31T16:27:54Z

When a PCI device is detected, pdev->is_added is set to 1 and proc and sysfs entries are created. When the device is removed, pdev->is_added is checked for one and then device is detached with clearing of proc and sys entries and at end, pdev->is_added is set to 0. is_added and is_busmaster are bit fields in pci_dev structure sharing same memory location. A strange issue was observed with multiple removal and rescan of a PCIe NVMe device using sysfs commands where is_added flag was observed as zero instead of one while removing device and proc,sys entries are not cleared. This causes issue in later device addition with warning message "proc_dir_entry" already registered. Debugging revealed a race condition between the PCI core setting the is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue setting the is_busmaster bit in pci_set_master(). As these fields are not handled atomically, that clears the is_added bit. Move the is_added bit to a separate private flag variable and use atomic functions to set and retrieve the device addition state. This avoids the race because is_added no longer shares a memory location with is_busmaster. Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283 Signed-off-by: Hari Vyas Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Acked-by: Michael Ellerman