kernel/linux.git/drivers/pci/remove.c, branch v7.2-rc1

PCI/sysfs: Remove pci_create_legacy_files() and pci_sysfs_init()

2026-06-23T20:19:09+00:00

Currently, pci_create_legacy_files() and pci_remove_legacy_files() are no-op stubs. With legacy attributes now handled by static groups registered via pcibus_groups[], no call site needs them. Remove both functions, their declarations, and the call sites in pci_register_host_bridge(), pci_alloc_child_bus(), and pci_remove_bus(). Remove the pci_sysfs_init() late_initcall and sysfs_initialized. The late_initcall originally existed to create all the dynamic PCI sysfs files, but with both resource and legacy attributes now handled by static groups, it is no longer needed. Remove the legacy_io and legacy_mem fields from struct pci_bus which were used to track the dynamically allocated legacy attributes. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Shivaprasad G Bhat Link: https://patch.msgid.link/20260508043543.217179-24-kwilczynski@kernel.org

PCI/sysfs: Remove pci_{create,remove}_sysfs_dev_files()

2026-06-23T20:19:09+00:00

Currently, pci_create_sysfs_dev_files() and pci_remove_sysfs_dev_files() are no-op stubs. With both the generic and Alpha resource files now handled by static attribute groups, no platform needs dynamic per-device sysfs file creation. Remove both functions, their declarations, and the call sites in pci_bus_add_device() and pci_stop_dev(). Remove __weak pci_create_resource_files() and pci_remove_resource_files() stubs and their declarations in pci.h, as no architecture overrides them anymore. Remove the res_attr[] and res_attr_wc[] fields from struct pci_dev which were used to track dynamically allocated resource attributes. Finally, simplify pci_sysfs_init() to only handle legacy file creation under HAVE_PCI_LEGACY, removing the per-device loop and the HAVE_PCI_SYSFS_INIT helper added earlier. Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Tested-by: Shivaprasad G Bhat Link: https://patch.msgid.link/20260508043543.217179-19-kwilczynski@kernel.org

PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs

2026-01-16T19:23:38+00:00

Adopt pwrctrl APIs to create, power on/off, and destroy pwrctrl devices. In qcom_pcie_host_init(), call pci_pwrctrl_create_devices() to create devices, then pci_pwrctrl_power_on_devices() to power them on, both after controller resource initialization. Once successful, deassert PERST# for all devices. In qcom_pcie_host_deinit(), call pci_pwrctrl_power_off_devices() after asserting PERST#. Note that pci_pwrctrl_destroy_devices() is not called here, as deinit is only invoked during system suspend where device destruction is unnecessary. If the driver becomes removable in future, pci_pwrctrl_destroy_devices() should be called in the remove() handler. Remove the old pwrctrl framework code from the PCI core (including devlinks) as the new APIs are now the sole consumer of pwrctrl functionality. And also do not power on the pwrctrl drivers during probe() as this is now handled by the APIs. Co-developed-by: Krishna Chaitanya Chundru Signed-off-by: Krishna Chaitanya Chundru Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Chen-Yu Tsai Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260115-pci-pwrctrl-rework-v5-12-9d26da3ce903@oss.qualcomm.com

PCI/IDE: Initialize an ID for all IDE streams

2025-11-14T23:06:57+00:00

The PCIe spec defines two types of streams - selective and link. Each stream has an ID from the same bucket so a stream ID does not tell the type. The spec defines an "enable" bit for every stream and required stream IDs to be unique among all enabled stream but there is no such requirement for disabled streams. However, when IDE_KM is programming keys, an IDE-capable device needs to know the type of stream being programmed to write it directly to the hardware as keys are relatively large, possibly many of them and devices often struggle with keeping around rather big data not being used. Walk through all streams on a device and initialise the IDs to some unique number, both link and selective. The weakest part of this proposal is the host bridge ide_stream_ids_ida. Technically, a Stream ID only needs to be unique within a given partner pair. However, with "anonymous" / unassigned streams there is no convenient place to track the available ids. Proceed with an ida in the host bridge for now, but consider moving this tracking to be an ide_stream_ids_ida per device. Co-developed-by: Alexey Kardashevskiy Signed-off-by: Alexey Kardashevskiy Reviewed-by: Jonathan Cameron Link: https://patch.msgid.link/20251113021446.436830-6-dan.j.williams@intel.com Signed-off-by: Dan Williams

PCI/TSM: Establish Secure Sessions and Link Encryption

2025-11-04T03:27:41+00:00

The PCIe 7.0 specification, section 11, defines the Trusted Execution Environment (TEE) Device Interface Security Protocol (TDISP). This protocol definition builds upon Component Measurement and Authentication (CMA), and link Integrity and Data Encryption (IDE). It adds support for assigning devices (PCI physical or virtual function) to a confidential VM such that the assigned device is enabled to access guest private memory protected by technologies like Intel TDX, AMD SEV-SNP, RISCV COVE, or ARM CCA. The "TSM" (TEE Security Manager) is a concept in the TDISP specification of an agent that mediates between a "DSM" (Device Security Manager) and system software in both a VMM and a confidential VM. A VMM uses TSM ABIs to setup link security and assign devices. A confidential VM uses TSM ABIs to transition an assigned device into the TDISP "RUN" state and validate its configuration. From a Linux perspective the TSM abstracts many of the details of TDISP, IDE, and CMA. Some of those details leak through at times, but for the most part TDISP is an internal implementation detail of the TSM. CONFIG_PCI_TSM adds an "authenticated" attribute and "tsm/" subdirectory to pci-sysfs. Consider that the TSM driver may itself be a PCI driver. Userspace can watch for the arrival of a "TSM" device, /sys/class/tsm/tsm0/uevent KOBJ_CHANGE, to know when the PCI core has initialized TSM services. The operations that can be executed against a PCI device are split into two mutually exclusive operation sets, "Link" and "Security" (struct pci_tsm_{link,security}_ops). The "Link" operations manage physical link security properties and communication with the device's Device Security Manager firmware. These are the host side operations in TDISP. The "Security" operations coordinate the security state of the assigned virtual device (TDI). These are the guest side operations in TDISP. Only "link" (Secure Session and physical Link Encryption) operations are defined at this stage. There are placeholders for the device security (Trusted Computing Base entry / exit) operations. The locking allows for multiple devices to be executing commands simultaneously, one outstanding command per-device and an rwsem synchronizes the implementation relative to TSM registration/unregistration events. Thanks to Wu Hao for his work on an early draft of this support. Cc: Lukas Wunner Cc: Samuel Ortiz Acked-by: Bjorn Helgaas Reviewed-by: Jonathan Cameron Reviewed-by: Alexey Kardashevskiy Co-developed-by: Xu Yilun Signed-off-by: Xu Yilun Link: https://patch.msgid.link/20251031212902.2256310-5-dan.j.williams@intel.com Signed-off-by: Dan Williams

Merge branch 'pci/virtualization'

2025-10-03T17:13:12+00:00

- Add rescan/remove locking when enabling/disabling SR-IOV, which solves list corruption on s390, where disabling SR-IOV also generates hotplug events (Niklas Schnelle) - Add lockdep assertion in pci_stop_and_remove_bus_device() to catch device removal without appropriate locking (Niklas Schnelle) * pci/virtualization: PCI: Add lockdep assertion in pci_stop_and_remove_bus_device() PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV

PCI: Add lockdep assertion in pci_stop_and_remove_bus_device()

2025-09-26T21:01:17+00:00

Removing a PCI devices requires holding pci_rescan_remove_lock. Prompted by this being missed in sriov_disable() and going unnoticed since its inception, add a lockdep assert so this doesn't get missed again in the future. Signed-off-by: Niklas Schnelle Signed-off-by: Bjorn Helgaas Reviewed-by: Benjamin Block Reviewed-by: Julian Ruess Link: https://patch.msgid.link/20250826-pci_fix_sriov_disable-v1-2-2d0bc938f2a3@linux.ibm.com

PCI/pwrctrl: Fix device leak at device stop

2025-08-27T19:32:25+00:00

Make sure to drop the reference to the pwrctrl device taken by of_find_device_by_node() when stopping a PCI device. Fixes: 681725afb6b9 ("PCI/pwrctl: Remove pwrctl device without iterating over all children of pwrctl parent") 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-4-johan+linaro@kernel.org

Merge branch 'pci/devtree-create'

2025-03-27T18:14:45+00:00

- Add device_add_of_node() to set dev->of_node and dev->fwnode only if they haven't been set already (Herve Codina) - Allow of_pci_set_address() to set the DT address property for root bus nodes, where there is no PCI bridge to supply the PCI bus/device/function part of the property (Herve Codina) - Create DT nodes for PCI host bridges to enable loading device tree overlays to create platform devices for PCI devices that have several features that require multiple drivers (Herve Codina) * pci/devtree-create: PCI: of: Create device tree PCI host bridge node PCI: of_property: Constify parameter in of_pci_get_addr_flags() PCI: of_property: Add support for NULL pdev in of_pci_set_address() PCI: of: Use device_{add,remove}_of_node() to attach of_node to existing device driver core: Introduce device_{add,remove}_of_node()

Merge branch 'pci/pwrctrl'

2025-03-27T18:14:44+00:00

- Create pwrctrl devices in pci_scan_device() to make it more symmetric with pci_pwrctrl_unregister() and make pwrctrl devices for PCI bridges possible (Manivannan Sadhasivam) - Unregister pwrctrl devices in pci_destroy_dev() so DOE, ASPM, etc. can still access devices after pci_stop_dev() (Manivannan Sadhasivam) - If there's a pwrctrl device for a PCI device, skip scanning it because the pwrctrl core will rescan the bus after the device is powered on (Manivannan Sadhasivam) - Add a pwrctrl driver for PCI slots based on voltage regulators described via devicetree (Manivannan Sadhasivam) * pci/pwrctrl: PCI/pwrctrl: Add pwrctrl driver for PCI slots dt-bindings: vendor-prefixes: Document the 'pciclass' prefix PCI/pwrctrl: Skip scanning for the device further if pwrctrl device is created PCI/pwrctrl: Move pci_pwrctrl_unregister() to pci_destroy_dev() PCI/pwrctrl: Move creation of pwrctrl devices to pci_scan_device()