Re: [PATCH v2 1/3] spi: nxp-fspi: use devm runtime PM enablement

[email protected]
Newsgroups dev.linux.lists.imx
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing pm_runtime_disable() from nxp_fspi_cleanup() while keeping manual clock disablement causes a deterministic double clock disable (reference count underflow) on driver unbind and probe error paths.
--

--- Patch [1]: [PATCH v2 1/3] spi: nxp-fspi: use devm runtime PM enablement ---
commit 274e174a430a74bbdd5c40d6aaca37aea56ac764
Author: Jiawen Liu <[email protected]>

spi: nxp-fspi: use devm runtime PM enablement

This commit replaces open-coded runtime PM enablement with
devm_pm_runtime_enable() and uses PM_RUNTIME_ACQUIRE_AUTOSUSPEND() to
simplify the error path and avoid leaving runtime PM state behind on
failure.

> diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
> index 1e36ae084dd86..6be78712b5343 100644
> --- a/drivers/spi/spi-nxp-fspi.c
> +++ b/drivers/spi/spi-nxp-fspi.c
> @@ -1275,7 +1275,6 @@ static void nxp_fspi_cleanup(void *data)
>  	/* disable the hardware */
>  	fspi_writel(f, FSPI_MCR0_MDIS, f->iobase + FSPI_MCR0);
>  
> -	pm_runtime_disable(f->dev);
>  	pm_runtime_put_noidle(f->dev);
>  	nxp_fspi_clk_disable_unprep(f);

[Severity: High]
Does removing pm_runtime_disable() here cause a double clock disable
during driver unbind or late probe failure?

When devres executes nxp_fspi_cleanup(), it drops the usage count via
pm_runtime_put_noidle() and manually disables the clocks with
nxp_fspi_clk_disable_unprep(). However, the device remains in the
RPM_ACTIVE state.

Later in the devres cleanup phase, the action registered by
devm_pm_runtime_enable() executes and clears autosuspend. Because the PM
usage count is 0 and autosuspend is now disabled, the PM core
synchronously transitions the device to RPM_SUSPENDED by executing the
driver's runtime suspend callback.

Will the runtime suspend callback then blindly invoke
nxp_fspi_clk_disable_unprep() a second time, triggering a clock reference
count underflow?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.