Re: [PATCH v9] ata: add <linux/pm_runtime.h> where missing

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the sata_rcar driver uses asynchronous pm_runtime_put() immediately before pm_runtime_disable(), which can leave hardware in an incorrect power state.
--

--- Patch [1]: [PATCH v9] ata: add <linux/pm_runtime.h> where missing ---
commit a948ddb3d02a94769e1f9fcb8c82c720adc71ef2
Author: Vladimir Oltean <vladimir.oltean@nxp.com>

ata: add <linux/pm_runtime.h> where missing

This commit adds the <linux/pm_runtime.h> header to several AHCI drivers
that use runtime PM operations. Previously, this header was indirectly
provided by <linux/phy/phy.h>, which is dropping it.

> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 58f512f8952a9..d1cdbf86da78d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but while reviewing runtime PM usage in the
ATA subsystem, I noticed a potential problem in sata_rcar.c that might cause
power resource leaks.

In sata_rcar.c, during the error path of sata_rcar_probe():

drivers/ata/sata_rcar.c:sata_rcar_probe() {
    ...
err_pm_put:
	pm_runtime_put(dev);
	pm_runtime_disable(dev);
    ...
}

And similarly during driver teardown in sata_rcar_remove():

drivers/ata/sata_rcar.c:sata_rcar_remove() {
    ...
	pm_runtime_put(&pdev->dev);
	pm_runtime_disable(&pdev->dev);
    ...
}

Does this sequence leave the hardware in an active power state? Calling
pm_runtime_disable() immediately after pm_runtime_put() cancels any pending
asynchronous suspend work. 

Should these paths use pm_runtime_put_sync() instead to ensure the idle
check and suspension complete synchronously before PM is disabled?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260810132502.460566-1-vladimir.oltean@nxp.com?part=1