[PATCH] PCI: qcom-ep: Clear runtime PM error after pm_runtime_resume_and_get() fails

[PATCH] PCI: qcom-ep: Clear runtime PM error after pm_runtime_resume_and_get() fails

[Mrinmay Sarkar]

pm_runtime_resume_and_get() sets dev->power.runtime_error when a runtime
resume fails. As a result, subsequent runtime PM resume requests fail
immediately until the error state is cleared.

In qcom_pcie_perst_deassert(), a failed resume during PERST# deassertion
leaves the endpoint controller stuck in runtime_error state. Any subsequent
PERST# deassert event that attempts to resume the controller will also fail.

Call pm_runtime_set_suspended() on the error path to clear the runtime
PM error state and allow future resume attempts.

Signed-off-by: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com>
---
This patch fixes a runtime PM recovery issue in the Qualcomm PCIe
endpoint driver.

A failed pm_runtime_resume_and_get() call during PERST# deassert leaves
the device in runtime_error state, causing subsequent resume attempts
to fail. Reset the runtime PM state on the error path to allow future
resume attempts.

Thanks,
Mrinmay
---
 drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
index 8364696a1b98..5a3dfea702ce 100644
--- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
+++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
@@ -404,6 +404,7 @@ static int qcom_pcie_perst_deassert(struct dw_pcie *pci)
 	ret = pm_runtime_resume_and_get(dev);
 	if (ret < 0) {
 		dev_err(dev, "Failed to enable device: %d\n", ret);
+		pm_runtime_set_suspended(dev);
 		return ret;
 	}
 

---
base-commit: 4c253ac4b29b8c6cc6fdef8f92d4facde62e63b9
change-id: 20260925-pcie-ep-rpm-fix-b288a0b36464

Best regards,
--  
Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com>

Re: [PATCH] PCI: qcom-ep: Clear runtime PM error after pm_runtime_resume_and_get() fails

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pm: ineffective pm_runtime_set_suspended() due to false runtime_error assumption
--

commit 3d108ba33ceb10b064e31ea4a0bb76a46a7b974e
Author: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com>

PCI: qcom-ep: Clear runtime PM error after pm_runtime_resume_and_get() fails

This patch attempts to fix a runtime PM recovery issue in the Qualcomm PCIe
endpoint driver. It adds a call to pm_runtime_set_suspended() on the error
path of pm_runtime_resume_and_get() in qcom_pcie_perst_deassert() to reset
the runtime PM state and allow future resume attempts.

> pm_runtime_resume_and_get() sets dev->power.runtime_error when a runtime
> resume fails. As a result, subsequent runtime PM resume requests fail
> immediately until the error state is cleared.

Is this description accurate?

Looking at the PM core in drivers/base/power/runtime.c, rpm_resume() does not
set dev->power.runtime_error upon failure. Instead, it merely updates
runtime_status to RPM_SUSPENDED. It appears only rpm_suspend() sets
runtime_error when a suspend operation fails.

> diff --git a/drivers/pci/controller/dwc/pcie-qcom-ep.c b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> index 8364696a1b980..5a3dfea702cee 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom-ep.c
> @@ -404,6 +404,7 @@ static int qcom_pcie_perst_deassert(struct dw_pcie *pci)
>  	ret = pm_runtime_resume_and_get(dev);
>  	if (ret < 0) {
>  		dev_err(dev, "Failed to enable device: %d\n", ret);
> +		pm_runtime_set_suspended(dev);

[Severity: Medium]
Will this call to pm_runtime_set_suspended() actually be a silent no-op?

pm_runtime_set_suspended() routes to __pm_runtime_set_status(), which
contains an early check:

    if (dev->power.runtime_error || dev->power.disable_depth)
        dev->power.disable_depth++;
    else
        error = -EAGAIN;
    ...
    if (error)
        return error;

Because runtime_error remains 0 (as the resume failure didn't set it) and
disable_depth is 0 (because runtime PM is enabled), the function returns
-EAGAIN and aborts immediately without clearing any state. Does this leave the
underlying reason for repeated resume failures unfixed?

>  		return ret;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925-pcie-ep-rpm-fix-v1-1-855d56cce43b@oss.qualcomm.com?part=1