kernel/linux.git/drivers/pci/pwrctrl, branch v7.0-rc7

PCI/pwrctrl: Fix pci_pwrctrl_is_required() device node leak

2026-03-23T20:57:43+00:00

The for_each_endpoint_of_node() macro requires calling of_node_put() on the endpoint node when breaking out of the loop early. Add of_node_put(endpoint) before the early return to release the reference. Fixes: cf3287fb2c1f ("PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement") Signed-off-by: Felix Gu Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260323-pwctrl-v1-1-f5c03a2df7fb@gmail.com

PCI/pwrctrl: Do not power off on pwrctrl device removal

2026-03-23T20:25:32+00:00

With the move to explicit pwrctrl power on/off APIs, the caller, i.e., the PCI controller driver, should manage the power state. The pwrctrl drivers should not try to clean up or power off when they are removed, as this might end up disabling an already disabled regulator, causing a big warning. This can be triggered if a PCI controller driver's .remove() callback calls pci_pwrctrl_destroy_devices() after pci_pwrctrl_power_off_devices(). Drop the devm cleanup parts that turn off regulators from the pwrctrl drivers. Fixes: b921aa3f8dec ("PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIs") Signed-off-by: Chen-Yu Tsai Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Reviewed-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260226092234.3859740-1-wenst@chromium.org

PCI/pwrctrl: Create pwrctrl devices only for PCI device nodes

2026-03-16T22:30:43+00:00

A PCI host bridge node can have non-PCI child nodes (OPP tables, USB hub, etc.) as well as PCI device child nodes. Ensure that pwrctrl devices are only created for PCI device nodes by checking for the 'pci' prefix in the compatible property. Fixes: 4c4132489201 ("PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices") Reported-by: Bjorn Andersson Closes: https://lore.kernel.org/all/20260212-rb3gen2-upd-gl3590-v1-1-18fb04bb32b0@oss.qualcomm.com Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260223-pwrctrl-fixes-7-0-v2-2-97566dfb1809@oss.qualcomm.com

PCI/pwrctrl: Ensure that remote endpoint node parent has supply requirement

2026-03-16T22:30:39+00:00

If OF graph is used in the PCI device node, the pwrctrl core creates a pwrctrl device even if the remote endpoint doesn't have power supply requirements. Since the device doesn't have any power supply requirements, there was no pwrctrl driver to probe, leading to PCI controller driver probe deferral as it waits for all pwrctrl drivers to probe before starting bus scan. This issue happens with Qcom ath12k devices with WSI interface attached to the Qcom IPQ platforms. Fix this issue by checking for the existence of at least one power supply property in the remote endpoint parent node. To consolidate all the checks, create a new helper pci_pwrctrl_is_required() and move all the checks there. Fixes: 9db826206f9b ("PCI/pwrctrl: Create pwrctrl device if graph port is found") Reported-by: Raj Kumar Bhagat Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Raj Kumar Bhagat Reviewed-by: Krishna Chaitanya Chundru Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260223-pwrctrl-fixes-7-0-v2-1-97566dfb1809@oss.qualcomm.com

PCI/pwrctrl: Create pwrctrl device if graph port is found

2026-01-29T21:04:26+00:00

The devicetree node of the PCIe Root Port/Slot could have the graph port to link the PCIe M.2 connector node. Since the M.2 connectors are modeled as Power Sequencing devices, they need to be controlled by the pwrctrl driver like the Root Port/Slot supplies. Hence, create the pwrctrl device if the graph port is found in the node. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260128-pci-m2-v7-2-9b3a5fe3d244@oss.qualcomm.com

PCI/pwrctrl: Add PCIe M.2 connector support

2026-01-28T16:39:17+00:00

Add support for handling PCIe M.2 connectors as Power Sequencing devices. These connectors are exposed as Power Sequencing devices as they often support multiple interfaces like PCIe/SATA, USB/UART to the host machine, and the interfaces may be driven by different client drivers at the same time. This driver handles the PCIe interface of these connectors. It first checks for the presence of the graph port in the Root Port node with the help of of_graph_is_present() API. If present, it acquires/powers ON the corresponding pwrseq device. Once the pwrseq device is powered ON, the driver will skip parsing the Root Port/Slot resources and register with the pwrctrl framework. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260128-pci-m2-v7-1-9b3a5fe3d244@oss.qualcomm.com

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/pwrctrl: Add APIs to power on/off pwrctrl devices

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

To fix bridge resource allocation issues when powering PCI bridges with the pwrctrl driver, introduce APIs to explicitly power on and off all related devices simultaneously. Previously, the individual pwrctrl drivers powered on/off the PCI devices autonomously, without any control from the controller drivers. But to enforce ordering with respect to powering on the devices, these APIs will power on/off all the devices at the same time. The pci_pwrctrl_power_on_devices() API recursively scans the PCI child nodes, makes sure that pwrctrl drivers are bound to devices, and calls their power_on() callbacks. If any pwrctrl driver is not bound, it will return -EPROBE_DEFER. Similarly, pci_pwrctrl_power_off_devices() API powers off devices recursively via their power_off() callbacks. These APIs are expected to be called during the controller probe and suspend/resume time to power on/off the devices. But before calling these APIs, the pwrctrl devices should be created using the pci_pwrctrl_{create/destroy}_devices() 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-11-9d26da3ce903@oss.qualcomm.com

PCI/pwrctrl: Add APIs to create, destroy pwrctrl devices

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

Previously, the PCI core created pwrctrl devices during pci_scan_device() on its own and then skipped enumeration of those devices, hoping the pwrctrl driver would power them on and trigger a bus rescan. This approach works for endpoint devices directly connected to Root Ports, but it fails for PCIe switches acting as bus extenders. When the switch requires pwrctrl support and the pwrctrl driver is not available during the pwrctrl device creation, its enumeration will be skipped during the initial PCI bus scan. This premature scan leads the PCI core to allocate resources (bridge windows, bus numbers) for the upstream bridge based on available downstream buses at scan time. For non-hotplug capable bridges, PCI core typically allocates resources based on the number of buses available during the initial bus scan, which happens to be just one if the switch is not powered on and enumerated at that time. When the switch gets enumerated later on, it will fail due to the lack of upstream resources. As a result, a PCIe switch powered on by the pwrctrl driver cannot be reliably enumerated currently. Either the switch has to be enabled in the bootloader or the switch pwrctrl driver has to be loaded during the pwrctrl device creation time to work around these issues. Introduce new APIs to explicitly create and destroy pwrctrl devices from controller drivers by recursively scanning the PCI child nodes of the controller. These APIs allow creating pwrctrl devices based on the original criteria and are intended to be called during controller probe and removal. These APIs, together with the upcoming APIs for power on/off will allow the controller drivers to power on all the devices before starting the initial bus scan, thereby solving the resource allocation issue. Signed-off-by: Krishna Chaitanya Chundru [mani: splitted the patch, cleaned up the code, and rewrote description] 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-10-9d26da3ce903@oss.qualcomm.com

PCI/pwrctrl: Add 'struct pci_pwrctrl::power_{on/off}' callbacks

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

To allow the pwrctrl core to control the power on/off sequences of the pwrctrl drivers, add the 'struct pci_pwrctrl::power_{on/off}' callbacks and populate them in the respective pwrctrl drivers. The pwrctrl drivers still power on the resources on their own now. So there is no functional change. 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-9-9d26da3ce903@oss.qualcomm.com