kernel/drivers/pci/bus.c, branch 0x221E-v0.0.1-v6.19

PCI/PM: Prevent runtime suspend until devices are fully initialized

2026-03-04T12:21:23Z

[ Upstream commit 51c0996dadaea20d73eb0495aeda9cb0422243e8 ] Previously, it was possible for a PCI device to be runtime-suspended before it was fully initialized. When that happened, the suspend process could save invalid device state, for example, before BAR assignment. Restoring the invalid state during resume may leave the device non-functional. Prevent runtime suspend for PCI devices until they are fully initialized by deferring pm_runtime_enable(). More details on how exactly this may occur: 1. PCI device is created by pci_scan_slot() or similar 2. As part of pci_scan_slot(), pci_pm_init() puts the device in D0 and prevents runtime suspend prevented via pm_runtime_forbid() 3. pci_device_add() adds the underlying 'struct device' via device_add(), which means user space can allow runtime suspend, e.g., echo auto > /sys/bus/pci/devices/.../power/control 4. PCI device receives BAR configuration (pci_assign_unassigned_bus_resources(), etc.) 5. pci_bus_add_device() applies final fixups, saves device state, and tries to attach a driver The device may potentially be suspended between #3 and #5, so this is racy with user space (udev or similar). Many PCI devices are enumerated at subsys_initcall time and so will not race with user space, but devices created later by hotplug or modular pwrctrl or host controller drivers are susceptible to this race. More runtime PM details at the first Link: below. Link: https://lore.kernel.org/all/0e35a4e1-894a-47c1-9528-fc5ffbafd9e2@samsung.com/ Signed-off-by: Brian Norris [bhelgaas: update comments per https://lore.kernel.org/r/CAJZ5v0iBNOmMtqfqEbrYyuK2u+2J2+zZ-iQd1FvyCPjdvU2TJg@mail.gmail.com] Signed-off-by: Bjorn Helgaas Tested-by: Marek Szyprowski Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260122094815.v5.1.I60a53c170a8596661883bd2b4ef475155c7aa72b@changeid Signed-off-by: Sasha Levin

Merge tag 'tsm-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm

2025-12-06T18:15:41Z

Pull PCIe Link Encryption and Device Authentication from Dan Williams: "New PCI infrastructure and one architecture implementation for PCIe link encryption establishment via platform firmware services. This work is the result of multiple vendors coming to consensus on some core infrastructure (thanks Alexey, Yilun, and Aneesh!), and three vendor implementations, although only one is included in this pull. The PCI core changes have an ack from Bjorn, the crypto/ccp/ changes have an ack from Tom, and the iommu/amd/ changes have an ack from Joerg. PCIe link encryption is made possible by the soup of acronyms mentioned in the shortlog below. Link Integrity and Data Encryption (IDE) is a protocol for installing keys in the transmitter and receiver at each end of a link. That protocol is transported over Data Object Exchange (DOE) mailboxes using PCI configuration requests. The aspect that makes this a "platform firmware service" is that the key provisioning and protocol is coordinated through a Trusted Execution Envrionment (TEE) Security Manager (TSM). That is either firmware running in a coprocessor (AMD SEV-TIO), or quasi-hypervisor software (Intel TDX Connect / ARM CCA) running in a protected CPU mode. Now, the only reason to ask a TSM to run this protocol and install the keys rather than have a Linux driver do the same is so that later, a confidential VM can ask the TSM directly "can you certify this device?". That precludes host Linux from provisioning its own keys, because host Linux is outside the trust domain for the VM. It also turns out that all architectures, save for one, do not publish a mechanism for an OS to establish keys in the root port. So "TSM-established link encryption" is the only cross-architecture path for this capability for the foreseeable future. This unblocks the other arch implementations to follow in v6.20/v7.0, once they clear some other dependencies, and it unblocks the next phase of work to implement the end-to-end flow of confidential device assignment. The PCIe specification calls this end-to-end flow Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP). In the meantime, Linux gets a link encryption facility which has practical benefits along the same lines as memory encryption. It authenticates devices via certificates and may protect against interposer attacks trying to capture clear-text PCIe traffic. Summary: - Introduce the PCI/TSM core for the coordination of device authentication, link encryption and establishment (IDE), and later management of the device security operational states (TDISP). Notify the new TSM core layer of PCI device arrival and departure - Add a low level TSM driver for the link encryption establishment capabilities of the AMD SEV-TIO architecture - Add a library of helpers TSM drivers to use for IDE establishment and the DOE transport - Add skeleton support for 'bind' and 'guest_request' operations in support of TDISP" * tag 'tsm-for-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm: (23 commits) crypto/ccp: Fix CONFIG_PCI=n build virt: Fix Kconfig warning when selecting TSM without VIRT_DRIVERS crypto/ccp: Implement SEV-TIO PCIe IDE (phase1) iommu/amd: Report SEV-TIO support psp-sev: Assign numbers to all status codes and add new ccp: Make snp_reclaim_pages and __sev_do_cmd_locked public PCI/TSM: Add 'dsm' and 'bound' attributes for dependent functions PCI/TSM: Add pci_tsm_guest_req() for managing TDIs PCI/TSM: Add pci_tsm_bind() helper for instantiating TDIs PCI/IDE: Initialize an ID for all IDE streams PCI/IDE: Add Address Association Register setup for downstream MMIO resource: Introduce resource_assigned() for discerning active resources PCI/TSM: Drop stub for pci_tsm_doe_transfer() drivers/virt: Drop VIRT_DRIVERS build dependency PCI/TSM: Report active IDE streams PCI/IDE: Report available IDE streams PCI/IDE: Add IDE establishment helpers PCI: Establish document for PCI host bridge sysfs attributes PCI: Add PCIe Device 3 Extended Capability enumeration PCI/TSM: Establish Secure Sessions and Link Encryption ...

PCI/ERR: Ensure error recoverability at all times

2025-11-24T22:58:33Z

When the PCI core gained power management support in 2002, it introduced pci_save_state() and pci_restore_state() helpers to restore Config Space after a D3hot or D3cold transition, which implies a Soft or Fundamental Reset (PCIe r7.0 sec 5.8): https://git.kernel.org/tglx/history/c/a5287abe398b In 2006, EEH and AER were introduced to recover from errors by performing a reset. Because errors can occur at any time, drivers began calling pci_save_state() on probe to ensure recoverability. In 2009, recoverability was foiled by commit c82f63e411f1 ("PCI: check saved state before restore"): It amended pci_restore_state() to bail out if the "state_saved" flag has been cleared. The flag is cleared by pci_restore_state() itself, hence a saved state is now allowed to be restored only once and is then invalidated. That doesn't seem to make sense because the saved state should be good enough to be reused. Soon after, drivers began to work around this behavior by calling pci_save_state() immediately after pci_restore_state(), see e.g. commit b94f2d775a71 ("igb: call pci_save_state after pci_restore_state"). Hilariously, two drivers even set the "saved_state" flag to true before invoking pci_restore_state(), see ipr_reset_restore_cfg_space() and e1000_io_slot_reset(). Despite these workarounds, recoverability at all times is not guaranteed: E.g. when a PCIe port goes through a runtime suspend and resume cycle, the "saved_state" flag is cleared by: pci_pm_runtime_resume() pci_pm_default_resume_early() pci_restore_state() ... and hence on a subsequent AER event, the port's Config Space cannot be restored. Riana reports a recovery failure of a GPU-integrated PCIe switch and has root-caused it to the behavior of pci_restore_state(). Another workaround would be necessary, namely calling pci_save_state() in pcie_port_device_runtime_resume(). The motivation of commit c82f63e411f1 was to prevent restoring state if pci_save_state() hasn't been called before. But that can be achieved by saving state already on device addition, after Config Space has been initialized. A desirable side effect is that devices become recoverable even if no driver gets bound. This renders the commit unnecessary, so revert it. Reported-by: Riana Tauro # off-list Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Tested-by: Riana Tauro Reviewed-by: Rafael J. Wysocki (Intel) Link: https://patch.msgid.link/9e34ce61c5404e99ffdd29205122c6fb334b38aa.1763483367.git.lukas@wunner.de

PCI: Introduce pci_walk_bus_reverse(), for_each_pci_dev_reverse()

2025-11-04T03:27:40Z

PCI/TSM, the PCI core functionality for the PCIe TEE Device Interface Security Protocol (TDISP), has a need to walk all subordinate functions of a Device Security Manager (DSM) to setup a device security context. A DSM is physical function 0 of multi-function or SR-IOV device endpoint, or it is an upstream switch port. In error scenarios or when a TEE Security Manager (TSM) device is removed it needs to unwind all established DSM contexts. Introduce reverse versions of PCI device iteration helpers to mirror the setup path and ensure that dependent children are handled before parents. Cc: Greg Kroah-Hartman Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20251031212902.2256310-4-dan.j.williams@intel.com Signed-off-by: Dan Williams

Merge branch 'pci/resource'

2025-10-03T17:13:12Z

- Ensure relaxed tail alignment does not increase min_align when computing bridge window size, to fix a regression (Ilpo Järvinen) - Fix bridge window size computation to fix a regression for devices with undefined PCI class, e.g., Samsung [144d:a5a5] (Ilpo Järvinen) - Fix error handling during resource resize to fix a regression in amdgpu (Ilpo Järvinen) - Align m68k pcibios_enable_device() with other arches (Ilpo Järvinen) - Remove several sparc pcibios_enable_device() implementations that don't do anything beyond what pci_enable_resources() does (Ilpo Järvinen) - Remove mips pcibios_enable_resources() and use pci_enable_resources() instead (Ilpo Järvinen) - Refactor and simplify find_bus_resource_of_type() (Ilpo Järvinen) - Claim bridge windows before setting them up (Ilpo Järvinen) - Disable non-claimed bridge windows so the kernel's view matches the hardware configuration (Ilpo Järvinen) - Use pci_release_resource() instead of release_resource() to reduce code duplication and increase consistency (Ilpo Järvinen) - Enable bridges even if bridge window assignment fails (Ilpo Järvinen) - Preserve bridge window resource type flags when assignment fails because we may need it later (Ilpo Järvinen) - Add bridge window selection functions to make the selection consistent across the several places that do this (Ilpo Järvinen) - Warn if bridge window cannot be released when resizing BAR (Ilpo Järvinen) - Set up bridge resources before enumerating children so we can check whether child resources are inside bridge windows (Ilpo Järvinen) * pci/resource: PCI: Set up bridge resources earlier PCI: Don't print stale information about resource PCI: Alter misleading recursion to pci_bus_release_bridge_resources() PCI: Pass bridge window to pci_bus_release_bridge_resources() PCI: Add pci_setup_one_bridge_window() PCI: Refactor remove_dev_resources() to use pbus_select_window() PCI: Refactor distributing available memory to use loops PCI: Use pbus_select_window_for_type() during mem window sizing PCI: Use pbus_select_window() in space available checker PCI: Rename resource variable from r to res PCI: Use pbus_select_window_for_type() during IO window sizing PCI: Use pbus_select_window() during BAR resize PCI: Warn if bridge window cannot be released when resizing BAR PCI: Fix finding bridge window in pci_reassign_bridge_resources() PCI: Add bridge window selection functions PCI: Add defines for bridge window indexing PCI: Preserve bridge window resource type flags PCI: Enable bridge even if bridge window fails to assign PCI: Use pci_release_resource() instead of release_resource() PCI: Disable non-claimed bridge window PCI: Always claim bridge window before its setup PCI: Refactor find_bus_resource_of_type() logic checks PCI: Move find_bus_resource_of_type() earlier MIPS: PCI: Use pci_enable_resources() sparc/PCI: Remove pcibios_enable_device() as they do nothing extra m68k/PCI: Use pci_enable_resources() in pcibios_enable_device() PCI: Fix failure detection during resource resize PCI: Fix pdev_resources_assignable() disparity PCI: Ensure relaxed tail alignment does not increase min_align

PCI: Preserve bridge window resource type flags

2025-09-16T16:19:18Z

When a bridge window is found unused or fails to assign, the flags of the associated resource are cleared. Clearing flags is problematic as it also removes the type information of the resource which is needed later. Thus, always preserve the bridge window type flags and use IORESOURCE_UNSET and IORESOURCE_DISABLED to indicate the status of the bridge window. Also, when initializing resources, make sure all valid bridge windows do get their type flags set. Change various places that relied on resource flags being cleared to check for IORESOURCE_UNSET and IORESOURCE_DISABLED to allow bridge window resource to retain their type flags. Add pdev_resource_assignable() and pdev_resource_should_fit() helpers to filter out disabled bridge windows during resource fitting; the latter combines more common checks into the helper. When reading the bridge windows from the registers, instead of leaving the resource flags cleared for bridge windows that are not enabled, always set up the flags and set IORESOURCE_UNSET | IORESOURCE_DISABLED as needed. When resource fitting or assignment fails for a bridge window resource, or the bridge window is not needed, mark the resource with IORESOURCE_UNSET or IORESOURCE_DISABLED, respectively. Use dummy zero resource in resource_show() for backwards compatibility as lspci will otherwise misrepresent disabled bridge windows. This change fixes an issue which highlights the importance of keeping the resource type flags intact: At the end of __assign_resources_sorted(), reset_resource() is called, previously clearing the flags. Later, pci_prepare_next_assign_round() attempted to release bridge resources using pci_bus_release_bridge_resources() that calls into pci_bridge_release_resources() that assumes type flags are still present. As type flags were cleared, IORESOURCE_MEM_64 was not set leading to resources under an incorrect bridge window to be released (idx = 1 instead of idx = 2). While the assignments performed later covered this problem so that the wrongly released resources got assigned in the end, it was still causing extra release+assign pairs. There are other reasons why the resource flags should be retained in upcoming changes too. Removing the flag reset for non-bridge window resource is left as future work, in part because it has a much higher regression potential due to pci_enable_resources() that will start to work also for those resources then and due to what endpoint drivers might assume about resources. Despite the Fixes tag, backporting this (at least any time soon) is highly discouraged. The issue fixed is borderline cosmetic as the later assignments normally cover the problem entirely. Also there might be non-obvious dependencies. Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250829131113.36754-11-ilpo.jarvinen@linux.intel.com

PCI/pwrctrl: Fix device leak at registration

2025-08-27T19:31:45Z

Make sure to drop the reference to the pwrctrl device taken by of_find_device_by_node() when registering a PCI device. Fixes: b458ff7e8176 ("PCI/pwrctl: Ensure that pwrctl drivers are probed before PCI client drivers") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Helgaas Reviewed-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org # v6.13 Link: https://patch.msgid.link/20250721153609.8611-2-johan+linaro@kernel.org

PCI: Allow built-in drivers to use async initial probing

2025-07-15T16:23:33Z

The PCI core has historically not allowed built-in drivers to opt in to async initial probing: Drivers may set "PROBE_PREFER_ASYNCHRONOUS", but initial probing always happens synchronously. That's because the PCI core uses device_attach() instead of device_initial_probe(). Should a driver return -EPROBE_DEFER on initial probe, reprobing later on does honor the PROBE_PREFER_ASYNCHRONOUS setting. Modular drivers are also allowed to probe asynchronously, which is inconsistent. The choice of device_attach() is likely not deliberate: It was introduced in 2013 with commit 58d9a38f6fac ("PCI: Skip attaching driver in device_add()"), but asynchronous probing was added two years later with commit 765230b5f084 ("driver-core: add asynchronous probing support for drivers"). According to the kernel-doc of "enum probe_type", "the end goal is to switch the kernel to use asynchronous probing by default". To this end, use device_initial_probe() to allow asynchronous initial probing. The function returns void, making the return value check unnecessary. Initial PCI probing often takes on the order of seconds even on laptops, so this may speed up booting significantly. A small number of PCI drivers already opt in to asynchronous probing. Their maintainers (who are all cc'ed) should watch out for issues, now that asynchronous probing is not just allowed for deferred and modular probing, but also initial probing: hl_pci_driver drivers/accel/habanalabs/common/habanalabs_drv.c cxl_pci_driver drivers/cxl/pci.c quicki2c_driver drivers/hid/intel-thc-hid/intel-quicki2c/pci-quicki2c.c quickspi_driver drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c i801_driver drivers/i2c/busses/i2c-i801.c mei_me_driver drivers/misc/mei/pci-me.c mei_vsc_drv drivers/misc/mei/platform-vsc.c sdhci_driver drivers/mmc/host/sdhci-pci-core.c nvme_driver drivers/nvme/host/pci.c ehci_pci_driver drivers/usb/host/ehci-pci.c hvfb_pci_stub_driver drivers/video/fbdev/hyperv_fb.c All other driver maintainers may test asynchronous probing by specifying the command line parameter "driver_async_probe=drv_name1,drv_name2,...", and on success setting "probe_type = PROBE_PREFER_ASYNCHRONOUS" in the pci_driver struct. Signed-off-by: Lukas Wunner [bhelgaas: updated commit log per https://lore.kernel.org/r/aHYUh7WoDlhHckxd@wunner.de] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/53abe6f5ac7c631f95f5d061aa748b192eda0379.1751614426.git.lukas@wunner.de

PCI: Limit visibility of match_driver flag to PCI core

2025-05-15T13:40:52Z

Since commit 58d9a38f6fac ("PCI: Skip attaching driver in device_add()"), PCI enumeration is split into two steps: In the first step, all devices are published in sysfs with device_add(). In the second step, drivers are bound to the devices with device_attach(). To delay driver binding until the second step, a "bool match_driver" in struct pci_dev is used. Instead of a bool, use a bit in the "unsigned long priv_flags" to shrink struct pci_dev a little and prevent use of the bool outside the PCI core (as has happened with commit cbbc00be2ce3 ("iommu/amd: Prevent binding other PCI drivers to IOMMU PCI devices")). Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Signed-off-by: Krzysztof Wilczyński Link: https://patch.msgid.link/d22a9e5b81d6bd8dd1837607d6156679b3b1199c.1745572340.git.lukas@wunner.de

PCI/pwrctrl: Move creation of pwrctrl devices to pci_scan_device()

2025-02-20T10:59:02Z

Current way of creating pwrctrl devices requires iterating through the child devicetree nodes of the PCI bridge in pci_pwrctrl_create_devices(). Even though it works, it creates confusion as there is no symmetry between this and pci_pwrctrl_unregister() function that removes the pwrctrl devices. So to make these two functions symmetric, move the creation of pwrctrl devices to pci_scan_device(). During the scan of each device in a slot, the devicetree node (if exists) for the PCI device will be checked. If it has the supplies populated, then the pwrctrl device will be created. Since the PCI device scan happens so early, there would be no "struct pci_dev" available for the device. So the host bridge is used as the parent of all pwrctrl devices. One nice side effect of this move is that, it is now possible to have pwrctrl devices for PCI bridges as well (to control the supplies of PCI slots). Suggested-by: Lukas Wunner Tested-by: Bartosz Golaszewski Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250116-pci-pwrctrl-slot-v3-1-827473c8fbf4@linaro.org [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński