kernel/linux.git/drivers/pci/remove.c, branch v6.19.11

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()

PCI/DOE: Expose DOE features via sysfs

2025-03-21T21:36:01+00:00

PCIe r6.0 added support for Data Object Exchange (DOE). When DOE is supported, the DOE Discovery Feature must be implemented per PCIe r6.1, sec 6.30.1.1. DOE allows a requester to obtain information about the other DOE features supported by the device. The kernel already queries the DOE features supported and caches the values. Expose the values in sysfs to allow user space to determine which DOE features are supported by the PCIe device. By exposing the information to userspace, tools like lspci can relay the information to users. By listing all of the supported features we can allow userspace to parse the list, which might include vendor specific features as well as yet to be supported features. As the DOE Discovery feature must always be supported we treat it as a special named attribute case. This allows the usual PCI attribute_group handling to correctly create the doe_features directory when registering pci_doe_sysfs_group (otherwise it doesn't and sysfs_add_file_to_group() will seg fault). After this patch is supported you can see something like this when attaching a DOE device: $ ls /sys/devices/pci0000:00/0000:00:02.0//doe* 0001:01 0001:02 doe_discovery Link: https://lore.kernel.org/r/20250306075211.1855177-3-alistair@alistair23.me Signed-off-by: Alistair Francis [bhelgaas: drop pci_doe_sysfs_init() stub return, make DEVICE_ATTR_RO(doe_discovery) static] Signed-off-by: Bjorn Helgaas Reviewed-by: Jonathan Cameron

PCI: of: Create device tree PCI host bridge node

2025-02-28T21:13:51+00:00

PCI devices device tree nodes can be already created. This was introduced by commit 407d1a51921e ("PCI: Create device tree node for bridge"). In order to have device tree nodes related to PCI devices attached on their PCI root bus (the PCI bus handled by the PCI host bridge), a PCI root bus device tree node is needed. This root bus node will be used as the parent node of the first level devices scanned on the bus. On device tree based systems, this PCI root bus device tree node is set to the node of the related PCI host bridge. The PCI host bridge node is available in the device tree used to describe the hardware passed at boot. On non device tree based system (such as ACPI), a device tree node for the PCI host bridge or for the root bus does not exist. Indeed, the PCI host bridge is not described in a device tree used at boot simply because no device tree is passed at boot. The device tree PCI host bridge node creation needs to be done at runtime. This is done in the same way as for the creation of the PCI device nodes. I.e. node and properties are created based on computed information done by the PCI core. Also, as is done on device tree based systems, this PCI host bridge node is used for the PCI root bus. With this done, hardware available in a PCI device that doesn't follow the PCI model consisting in one PCI function handled by one driver can be described by a device tree overlay loaded by the PCI device driver on non device tree based systems. Those PCI devices provide a single PCI function that includes several functionalities that require different drivers. The device tree overlay describes the internal devices and their relationships. It allows to load drivers needed by those different devices in order to have functionalities handled. Link: https://lore.kernel.org/r/20250224141356.36325-6-herve.codina@bootlin.com Signed-off-by: Herve Codina Signed-off-by: Bjorn Helgaas Reviewed-by: Rob Herring (Arm)

PCI/pwrctrl: Move pci_pwrctrl_unregister() to pci_destroy_dev()

2025-02-20T10:59:10+00:00

The PCI core will try to access the devices even after pci_stop_dev() for things like Data Object Exchange (DOE), ASPM, etc. So, move pci_pwrctrl_unregister() to the near end of pci_destroy_dev() to make sure that the devices are powered down only after the PCI core is done with them. Suggested-by: Lukas Wunner Reviewed-by: Lukas Wunner Tested-by: Bartosz Golaszewski Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20250116-pci-pwrctrl-slot-v3-2-827473c8fbf4@linaro.org [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński