From: Lukasz Luba <lukasz.luba@arm.com>
To: Anand Moon <linux.amoon@gmail.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
"open list:SAMSUNG THERMAL DRIVER"
<linux-samsung-soc@vger.kernel.org>,
Alim Akhtar <alim.akhtar@samsung.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"open list:SAMSUNG THERMAL DRIVER" <linux-pm@vger.kernel.org>,
Zhang Rui <rui.zhang@intel.com>,
"moderated list:ARM/SAMSUNG S3C,
S5P AND EXYNOS ARM ARCHITECTURES"
<linux-arm-kernel@lists.infradead.org>,
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/4] drivers/thermal/exynos: Refactor clk_sec initialization inside SOC-specific case
Date: Fri, 28 Feb 2025 14:37:24 +0000 [thread overview]
Message-ID: <e101aff2-a08e-4fed-8e38-df1aea44d23e@arm.com> (raw)
In-Reply-To: <20250216195850.5352-2-linux.amoon@gmail.com>
Hi Anand,
On 2/16/25 19:58, Anand Moon wrote:
> Refactor the initialization of the clk_sec clock to be inside the
> SOC_ARCH_EXYNOS5420_TRIMINFO case. It ensures that the clk_sec clock
> is only initialized for the specified SOC and not for other SOCs,
> thereby simplifying the code.
So IIUC there was no need to init that clock for other types of SoCs...
Do we know that for sure (e.g. from other TRMs)?
If that was the case, then simplification here can go further, but after
some fixes.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> v3: improve the commit message
> ---
> drivers/thermal/samsung/exynos_tmu.c | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
> index 47a99b3c5395..9c138772d380 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -1040,19 +1040,6 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> if (IS_ERR(data->clk))
> return dev_err_probe(dev, PTR_ERR(data->clk), "Failed to get clock\n");
>
> - data->clk_sec = devm_clk_get(dev, "tmu_triminfo_apbif");
> - if (IS_ERR(data->clk_sec)) {
> - if (data->soc == SOC_ARCH_EXYNOS5420_TRIMINFO)
> - return dev_err_probe(dev, PTR_ERR(data->clk_sec),
> - "Failed to get triminfo clock\n");
> - } else {
> - ret = clk_prepare(data->clk_sec);
> - if (ret) {
> - dev_err(dev, "Failed to get clock\n");
> - return ret;
> - }
> - }
> -
> ret = clk_prepare(data->clk);
Here the data->clk is now used in different order.
> if (ret) {
> dev_err(dev, "Failed to get clock\n");
> @@ -1060,6 +1047,19 @@ static int exynos_tmu_probe(struct platform_device *pdev)
> }
>
> switch (data->soc) {
> + case SOC_ARCH_EXYNOS5420_TRIMINFO:
> + data->clk_sec = devm_clk_get(dev, "tmu_triminfo_apbif");
> + if (IS_ERR(data->clk_sec)) {
> + return dev_err_probe(dev, PTR_ERR(data->clk_sec),
> + "Failed to get triminfo clock\n");
Then here you shouldn't simply copy the old code. Now the data->clk
is first, so should be 'clk_unprepare()' before return of the function.
> + } else {
You can get rid of this 'else' above and still be safe in your
refactoring.
> + ret = clk_prepare(data->clk_sec);
> + if (ret) {
> + dev_err(dev, "Failed to get clock\n");
> + return ret;
> + }
Here you can further simplify this to something like:
-----------------------8<-------------------------------------
+ case SOC_ARCH_EXYNOS5420_TRIMINFO:
+ data->clk_sec = devm_clk_get(dev, "tmu_triminfo_apbif");
+ if (IS_ERR(data->clk_sec)) {
+ clk_unprepare(data->clk); ///// <----
+ return dev_err_probe(dev, PTR_ERR(data->clk_sec),
+ "Failed to get triminfo clock\n");
+ }
+ ret = clk_prepare(data->clk_sec);
+ if (ret) {
+ dev_err(dev, "Failed to get clock\n");
+ clk_unprepare(data->clk); ///// <----
+ return ret;
+ }
+
+ break;
--------------------------->8---------------------------------
Or with better 'goto' flow.
> + }
> + break;
> case SOC_ARCH_EXYNOS5433:
> case SOC_ARCH_EXYNOS7:
> data->sclk = devm_clk_get(dev, "tmu_sclk");
Also, you should revisit the 'goto' cleanup section at the bottom.
Regards,
Lukasz
next prev parent reply other threads:[~2025-02-28 14:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-16 19:58 [PATCH v3 0/4] Exynos Thermal code improvement Anand Moon
2025-02-16 19:58 ` [PATCH v3 1/4] drivers/thermal/exynos: Refactor clk_sec initialization inside SOC-specific case Anand Moon
2025-02-28 14:37 ` Lukasz Luba [this message]
2025-02-28 15:19 ` Anand Moon
2025-02-16 19:58 ` [PATCH v3 2/4] drivers/thermal/exymos: Remove redundant IS_ERR() checks for clk_sec clock Anand Moon
2025-02-28 16:50 ` Lukasz Luba
2025-02-16 19:58 ` [PATCH v3 3/4] drivers/thermal/exymos: Fixed the efuse min max value for exynos5422 Anand Moon
2025-02-16 19:58 ` [PATCH v3 4/4] drivers/thermal/exymos: Use guard notation when acquiring mutex Anand Moon
2025-02-28 17:28 ` Lukasz Luba
2025-02-28 18:36 ` Anand Moon
2025-03-04 12:20 ` Anand Moon
2025-03-05 8:42 ` Lukasz Luba
2025-03-05 15:59 ` Anand Moon
2025-03-06 9:15 ` Lukasz Luba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e101aff2-a08e-4fed-8e38-df1aea44d23e@arm.com \
--to=lukasz.luba@arm.com \
--cc=alim.akhtar@samsung.com \
--cc=bzolnier@gmail.com \
--cc=daniel.lezcano@linaro.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux.amoon@gmail.com \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).