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 <[email protected]>
---
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");
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
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 <[email protected]>
> ---
> 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;
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
>
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 <[email protected]>
>> ---
>> 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
>>
>
On Sun, May 14, 2023 at 07:00:34PM +0200, Christophe JAILLET wrote:
>
> Le 14/05/2023 à 17:35, Ondřej Jirman a écrit :
> > Hello Christophe,
> >
> > [...]
> >
> > 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?
That would be after reset_control_deassert(). devm_reset_control_get() is just
resource management, like devm_clk_get().
regards,
o.
Le 14/05/2023 à 19:10, Ondřej Jirman a écrit :
> On Sun, May 14, 2023 at 07:00:34PM +0200, Christophe JAILLET wrote:
>>
>> Le 14/05/2023 à 17:35, Ondřej Jirman a écrit :
>>> Hello Christophe,
>>>
>>> [...]
>>>
>>> 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?
>
> That would be after reset_control_deassert(). devm_reset_control_get() is just
> resource management, like devm_clk_get().
Not sure to get your point. I think you misunderstood what I tried to say.
I propose to move reset_control_deassert() in a v2. And have
devm_add_action_or_reset() just after it.
Something like:
if (tmdev->chip->has_bus_clk_reset) {
tmdev->reset = devm_reset_control_get(dev, NULL);
if (IS_ERR(tmdev->reset))
return PTR_ERR(tmdev->reset);
ret = reset_control_deassert(tmdev->reset);
if (ret)
return ret;
ret = devm_add_action_or_reset(dev, sun8i_ths_reset_control_assert,
tmdev->reset);
if (ret)
return ret;
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_enabled(&pdev->dev, "mod");
if (IS_ERR(tmdev->mod_clk))
return PTR_ERR(tmdev->mod_clk);
}
ret = clk_set_rate(tmdev->mod_clk, 24000000);
if (ret)
return ret;
This would keep the order of operation, still fix the leak in the probe
and still save some LoC.
Would it make it?
CJ
>
> regards,
> o.
>
On Sun, May 14, 2023 at 07:32:54PM +0200, Christophe JAILLET wrote:
>
> Le 14/05/2023 à 19:10, Ondřej Jirman a écrit :
> > On Sun, May 14, 2023 at 07:00:34PM +0200, Christophe JAILLET wrote:
> > >
> > > Le 14/05/2023 à 17:35, Ondřej Jirman a écrit :
> > > > Hello Christophe,
> > > >
> > > > [...]
> > > >
> > > > 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?
> >
> > That would be after reset_control_deassert(). devm_reset_control_get() is just
> > resource management, like devm_clk_get().
>
> Not sure to get your point. I think you misunderstood what I tried to say.
Yes, I just misread what you wrote. What you suggested is fine.
kind regards,
o.
>
> I propose to move reset_control_deassert() in a v2. And have
> devm_add_action_or_reset() just after it.
>
> Something like:
>
> if (tmdev->chip->has_bus_clk_reset) {
> tmdev->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(tmdev->reset))
> return PTR_ERR(tmdev->reset);
>
> ret = reset_control_deassert(tmdev->reset);
> if (ret)
> return ret;
>
> ret = devm_add_action_or_reset(dev, sun8i_ths_reset_control_assert,
> tmdev->reset);
> if (ret)
> return ret;
>
> 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_enabled(&pdev->dev, "mod");
> if (IS_ERR(tmdev->mod_clk))
> return PTR_ERR(tmdev->mod_clk);
> }
>
> ret = clk_set_rate(tmdev->mod_clk, 24000000);
> if (ret)
> return ret;
>
>
> This would keep the order of operation, still fix the leak in the probe and
> still save some LoC.
>
> Would it make it?
>
> CJ
>
> >
> > regards,
> > o.
> >
>