Re: [PATCH] PCI/pwrctrl: lock device when calling device_is_bound()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] If a device fails to power on (or is probe deferred), its successfully powered-on children and previous siblings within its subtree are not powered off, causing a resource leak.
--

commit 9be02f191b459f8fb2b5eb9ee177a3aa7076d6f1
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

PCI/pwrctrl: lock device when calling device_is_bound()

This commit adds device locking around device_is_bound() calls in the
PCI power control core to satisfy its kerneldoc requirements.

> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 97cff5b8ca885..cd08d590483b8 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c

[ ... ]

> @@ -205,7 +207,7 @@ static int __pci_pwrctrl_power_on_device(struct device *dev)
>  static int pci_pwrctrl_power_on_device(struct device_node *np)
>  {
>  	struct platform_device *pdev;
> -	int ret;
> +	int ret = 0;
>  
>  	for_each_available_child_of_node_scoped(np, child) {
>  		ret = pci_pwrctrl_power_on_device(child);
> @@ -217,12 +219,14 @@ static int pci_pwrctrl_power_on_device(struct device_node *np)
>  	if (!pdev)
>  		return 0;
>  
> -	if (device_is_bound(&pdev->dev)) {
> -		ret = __pci_pwrctrl_power_on_device(&pdev->dev);
> -	} else {
> -		/* FIXME: Use blocking wait instead of probe deferral */
> -		dev_dbg(&pdev->dev, "driver is not bound\n");
> -		ret = -EPROBE_DEFER;
> +	scoped_guard(device, &pdev->dev) {
> +		if (device_is_bound(&pdev->dev)) {
> +			ret = __pci_pwrctrl_power_on_device(&pdev->dev);
> +		} else {
> +			/* FIXME: Use blocking wait instead of probe deferral */
> +			dev_dbg(&pdev->dev, "driver is not bound\n");
> +			ret = -EPROBE_DEFER;
> +		}
>  	}
>  
>  	platform_device_put(pdev);

This problem wasn't introduced by this patch, but does returning here leak
resources on probe deferral?

If a device fails to power on or is probe deferred, the function returns
the error without reverting the state of the children that were already
successfully powered on in the for_each_available_child_of_node_scoped()
loop above.

The top-level caller pci_pwrctrl_power_on_devices() catches the error and
executes the err_power_off cleanup path, but that path only cleans up fully
successful top-level sibling trees up to the failing node. It appears to
skip the partially-powered subtree of the failing node itself.

Since probe deferrals are a normal and frequently repeated process during
system boot, could these leaked refcounts accumulate and eventually cause
resource exhaustion?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518100700.47581-1-bartosz.golaszewski@oss.qualcomm.com?part=1