Re: [PATCH v8 2/2] bus: simple-pm-bus: Populate child nodes at probe

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Time-of-Check to Time-of-Use (TOCTOU) race with the mutable driver_override sysfs attribute causes state mismatch and resource leaks.
- [High] The driver leaks clock enable counts during removal because pm_runtime_disable() is called without synchronously suspending the device.
--

commit 8879d2bb547d47c5c484809ff15676d13cfec9a8
Author: Herve Codina <herve.codina@bootlin.com>

bus: simple-pm-bus: Populate child nodes at probe

The simple-pm-bus driver didn't populate child devices during probe when used
with busses other than a compatible "simple-pm-bus", confusing fw_devlink.
This commit explicitly populates child nodes during probe for those compatible
devices to ensure proper devlink creation and consumer removal ordering.

> diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
> index 4b2a793dfbd90..d969bf19a4e95 100644
> --- a/drivers/bus/simple-pm-bus.c
> +++ b/drivers/bus/simple-pm-bus.c

[ ... ]

> @@ -78,7 +80,7 @@ static void simple_pm_bus_remove(struct platform_device *pdev)
>  {
>  	const void *data = of_device_get_match_data(&pdev->dev);
>  
> -	if (device_has_driver_override(&pdev->dev) || data)
> +	if (device_has_driver_override(&pdev->dev))

[Severity: High]
This isn't a bug introduced by this patch, but is it safe to rely on
device_has_driver_override() here during removal?

The driver_override sysfs attribute is mutable. If it is changed by a user
after probe() but before remove(), the control flow in remove() will skip
of_platform_depopulate() and pm_runtime_disable(), causing state mismatches.

If the override is cleared after being set during probe, remove() might
attempt to depopulate children it never populated and disable PM runtime it
never enabled.

Could this rely on the driver's own internal state (like dev_get_drvdata())
instead of checking a mutable sysfs attribute?

>  		return;
>  
>  	dev_dbg(&pdev->dev, "%s\n", __func__);
> @@ -86,7 +88,8 @@ static void simple_pm_bus_remove(struct platform_device *pdev)
>  	if (pdev->dev.of_node)
>  		of_platform_depopulate(&pdev->dev);
>  
> -	pm_runtime_disable(&pdev->dev);
> +	if (!data)
> +		pm_runtime_disable(&pdev->dev);

[Severity: High]
This is a pre-existing issue, but does calling pm_runtime_disable() here
without synchronously suspending the device leak clock enable counts?

of_platform_depopulate() removes the children, which may asynchronously drop
the bus's PM usage counter. Calling pm_runtime_disable() immediately
afterward cancels any pending async suspend requests.

If the parent bus remains RPM_ACTIVE when pm_runtime_disable() completes,
devm will free the clock structures without disabling them, permanently
leaking the clock references.

Should the driver synchronously suspend the device before disabling runtime PM?

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630102717.413501-1-herve.codina@bootlin.com?part=2