Re: [PATCH] spi: cadence-quadspi: Fix clock enable underflows due to runtime PM

["Dutta, Anurag" <a-dutta@ti.com>]

On 09-12-2025 16:00, Mark Brown wrote:
> On Tue, Dec 09, 2025 at 03:22:43PM +0530, Dutta, Anurag wrote:
>> On 09-12-2025 11:13, Dutta, Anurag wrote:
>> Another solution :
>> diff --git a/drivers/spi/spi-cadence-quadspi.c
>> b/drivers/spi/spi-cadence-quadspi.c
>> index af6d050da1c8..4d298b945f09 100644
>> --- a/drivers/spi/spi-cadence-quadspi.c
>> +++ b/drivers/spi/spi-cadence-quadspi.c
>> @@ -2024,7 +2024,11 @@ static int cqspi_probe(struct platform_device *pdev)
>>   probe_reset_failed:
>>          if (cqspi->is_jh7110)
>>                  cqspi_jh7110_disable_clk(pdev, cqspi);
>> -       clk_disable_unprepare(cqspi->clk);
>> +
>> +       if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) {
>> +               if (pm_runtime_get_sync(&pdev->dev) >= 0)
>> +                       clk_disable_unprepare(cqspi->clk);
>> +       }
>> pm_runtime_get_sync() will increment the usage count thereby preventing from
>> runtime_suspend()
>> getting invoked, thereby preventing double clock_disable()
>>
>> This will work for !CONFIG_PM as well because pm_runtime_get_sync() will
>> return 1 then.
>> and the runtime_suspend() is never going to be invoked.
> I think we want this, possibly using pm_runtime_force_resume() instead
> (not 100% sure on that one, glancing at the documentation there might be
> issues though it feels like the intent of what we're doing here).  Can
> you send a patch please?

> Hi Mark
> If we use pm_runtime_force_resume(), then for CONFIG_PM_SLEEP, it will work.
> But, in case of !CONFIG_PM_SLEEP, pm_runtime_force_resume() returns -ENXIO,
> because of which :
>
> if (pm_runtime_get_sync(&pdev->dev) >= 0)
>
> will be become false and clk_disable_unprepare() will never be invoked,
> which might be an issue.
>
> Let me send a patch with pm_runtime_get_sync(). If changes are required,
> please let me know.
>
> Regards
> Anurag