[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ae3f111-e13b-cdd7-317d-316585390952@wanadoo.fr>
Date: Sun, 14 May 2023 19:00:34 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Ondřej Jirman <megi@....cz>,
Vasily Khoruzhick <anarsoul@...il.com>,
Yangtao Li <tiny.windzz@...il.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Amit Kucheria <amitk@...nel.org>,
Zhang Rui <rui.zhang@...el.com>, Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Maxime Ripard <mripard@...nel.org>,
linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH] thermal/drivers/sun8i: Fix some error handling paths in
sun8i_ths_probe()
Le 14/05/2023 à 17:35, Ondřej Jirman a écrit :
> Hello Christophe,
>
> On Sun, May 14, 2023 at 05:21:35PM +0200, Christophe JAILLET wrote:
>>
>> Should an error occur after calling sun8i_ths_resource_init() in the probe
>> function, some resources need to be released, as already done in the
>> .remove() function.
>>
>> Switch to the devm_clk_get_enabled() helper and add a new devm_action to
>> turn sun8i_ths_resource_init() into a fully managed function.
>>
>> This fixes the issue and removes some LoC at the same time.
>>
>> Fixes: dccc5c3b6f30 ("thermal/drivers/sun8i: Add thermal driver for H6/H5/H3/A64/A83T/R40")
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>> ---
>> This changes the order of the release functions, but should be fine.
>> ---
>> drivers/thermal/sun8i_thermal.c | 43 +++++++++------------------------
>> 1 file changed, 12 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
>> index 793ddce72132..8f4c29bc85aa 100644
>> --- a/drivers/thermal/sun8i_thermal.c
>> +++ b/drivers/thermal/sun8i_thermal.c
>> @@ -319,6 +319,11 @@ static int sun8i_ths_calibrate(struct ths_device *tmdev)
>> return ret;
>> }
>>
>> +static void sun8i_ths_reset_control_assert(void *data)
>> +{
>> + reset_control_assert(data);
>> +}
>> +
>> static int sun8i_ths_resource_init(struct ths_device *tmdev)
>> {
>> struct device *dev = tmdev->dev;
>> @@ -339,13 +344,13 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
>> if (IS_ERR(tmdev->reset))
>> return PTR_ERR(tmdev->reset);
>>
>> - tmdev->bus_clk = devm_clk_get(&pdev->dev, "bus");
>> + tmdev->bus_clk = devm_clk_get_enabled(&pdev->dev, "bus");
>> if (IS_ERR(tmdev->bus_clk))
>> return PTR_ERR(tmdev->bus_clk);
>> }
>>
>> if (tmdev->chip->has_mod_clk) {
>> - tmdev->mod_clk = devm_clk_get(&pdev->dev, "mod");
>> + tmdev->mod_clk = devm_clk_get_enabled(&pdev->dev, "mod");
>
> This changes the recommeded order of reset release/clock enable steps, eg. A64
> manual says:
>
> 3.3.6.4. Gating and reset
>
> Make sure that the reset signal has been released before the release of
> module clock gating;
Ok, so moving reset_control_deassert() (and my proposed
devm_add_action_or_reset()) just after devm_reset_control_get() should
keep the expected order, right?
CJ
>
> kind regards,
> o.
>
>> if (IS_ERR(tmdev->mod_clk))
>> return PTR_ERR(tmdev->mod_clk);
>> }
>> @@ -354,32 +359,20 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev)
>> if (ret)
>> return ret;
>>
>> - ret = clk_prepare_enable(tmdev->bus_clk);
>> + ret = devm_add_action_or_reset(dev, sun8i_ths_reset_control_assert,
>> + tmdev->reset);
>> if (ret)
>> - goto assert_reset;
>> + return ret;
>>
>> ret = clk_set_rate(tmdev->mod_clk, 24000000);
>> if (ret)
>> - goto bus_disable;
>> -
>> - ret = clk_prepare_enable(tmdev->mod_clk);
>> - if (ret)
>> - goto bus_disable;
>> + return ret;
>>
>> ret = sun8i_ths_calibrate(tmdev);
>> if (ret)
>> - goto mod_disable;
>> + return ret;
>>
>> return 0;
>> -
>> -mod_disable:
>> - clk_disable_unprepare(tmdev->mod_clk);
>> -bus_disable:
>> - clk_disable_unprepare(tmdev->bus_clk);
>> -assert_reset:
>> - reset_control_assert(tmdev->reset);
>> -
>> - return ret;
>> }
>>
>> static int sun8i_h3_thermal_init(struct ths_device *tmdev)
>> @@ -530,17 +523,6 @@ static int sun8i_ths_probe(struct platform_device *pdev)
>> return 0;
>> }
>>
>> -static int sun8i_ths_remove(struct platform_device *pdev)
>> -{
>> - struct ths_device *tmdev = platform_get_drvdata(pdev);
>> -
>> - clk_disable_unprepare(tmdev->mod_clk);
>> - clk_disable_unprepare(tmdev->bus_clk);
>> - reset_control_assert(tmdev->reset);
>> -
>> - return 0;
>> -}
>> -
>> static const struct ths_thermal_chip sun8i_a83t_ths = {
>> .sensor_num = 3,
>> .scale = 705,
>> @@ -642,7 +624,6 @@ MODULE_DEVICE_TABLE(of, of_ths_match);
>>
>> static struct platform_driver ths_driver = {
>> .probe = sun8i_ths_probe,
>> - .remove = sun8i_ths_remove,
>> .driver = {
>> .name = "sun8i-thermal",
>> .of_match_table = of_ths_match,
>> --
>> 2.34.1
>>
>
Powered by blists - more mailing lists