[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250506095428.GB177796@e132581.arm.com>
Date: Tue, 6 May 2025 10:54:28 +0100
From: Leo Yan <leo.yan@....com>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>,
James Clark <james.clark@...aro.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH v2 4/9] coresight: Disable programming clock properly
On Fri, May 02, 2025 at 11:40:31AM +0530, Anshuman Khandual wrote:
> Even though this might seem to be being bike shedding, the subject
> line above could be re-organized something like the following for
> better clarity.
>
> coresight: Properly/Appropriately disable programming clocks
Sure. I will change the subject to this.
[...]
> > @@ -725,8 +723,6 @@ static void debug_platform_remove(struct platform_device *pdev)
> >
> > __debug_remove(&pdev->dev);
> > pm_runtime_disable(&pdev->dev);
> > - if (!IS_ERR_OR_NULL(drvdata->pclk))
> > - clk_put(drvdata->pclk);
> > }
> Should not these IS_ERR_OR_NULL() here be changed to IS_ERR() ?
For the case above, after changed to devm_clk_get_enabled() for the
enabling programming clocks, we don't need any special handling and
leave the clock disabling and releasing to the device model layer.
> Because now there could not be a NULL return value.
>
> drvdata->pclk = coresight_get_enable_apb_pclk(&pdev->dev)
>
> #ifdef CONFIG_PM
> static int debug_runtime_suspend(struct device *dev)
> {
> struct debug_drvdata *drvdata = dev_get_drvdata(dev);
>
> if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> clk_disable_unprepare(drvdata->pclk);
> return 0;
> }
>
> static int debug_runtime_resume(struct device *dev)
> {
> struct debug_drvdata *drvdata = dev_get_drvdata(dev);
>
> if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> clk_prepare_enable(drvdata->pclk);
> return 0;
> }
> #endif
> There might more instances like these as well.
>
> git grep IS_ERR_OR_NULL drivers/hwtracing/coresight/ | grep "drvdata->pclk"
> drivers/hwtracing/coresight/coresight-cpu-debug.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-cpu-debug.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-funnel.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-funnel.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-replicator.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-replicator.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-stm.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-stm.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-tpiu.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
> drivers/hwtracing/coresight/coresight-tpiu.c: if (drvdata && !IS_ERR_OR_NULL(drvdata->pclk))
I would like the current patch to focus on the issue of disabling /
releasing the programming clocks.
Though the IS_ERR_OR_NULL() check is redundant, it does not cause
issue or regression. The refactoring is left in patch 09 for removing
IS_ERR_OR_NULL() checks.
Does this make sense?
Thanks
Leo
Powered by blists - more mailing lists