[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1542ee8a-620b-4349-92fb-ab1f6c5b5eab@ti.com>
Date: Fri, 12 Dec 2025 10:04:47 +0530
From: "Dutta, Anurag" <a-dutta@...com>
To: Mark Brown <broonie@...nel.org>
CC: Nishanth Menon <nm@...com>, Francesco Dolcini <francesco@...cini.it>,
Siddharth Vadapalli <s-vadapalli@...com>, <linux-spi@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>, "Gujulan Elango,
Hari Prasath" <gehariprasath@...com>, "Kumar, Udit" <u-kumar1@...com>
Subject: Re: [PATCH] spi: cadence-quadspi: Fix clock enable underflows due to
runtime PM
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
Powered by blists - more mailing lists