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.
Move the place where reset_control_deassert() is called so that the
recommended order of reset release/clock enable steps is kept.
A64 manual states that:
3.3.6.4. Gating and reset
Make sure that the reset signal has been released before the release of
module clock gating;
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]>
---
Changes in v2:
- move reset_control_deassert() next to devm_reset_control_get()
v1: https://lore.kernel.org/all/26f9e3bb3fcd0c12ea24a44c75b7960da993b68b.1684077651.git.christophe.jaillet@wanadoo.fr/
---
drivers/thermal/sun8i_thermal.c | 55 +++++++++++----------------------
1 file changed, 18 insertions(+), 37 deletions(-)
diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
index 793ddce72132..d4d241686c81 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,47 +344,35 @@ 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");
+ 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(&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);
}
- ret = reset_control_deassert(tmdev->reset);
- if (ret)
- return ret;
-
- ret = clk_prepare_enable(tmdev->bus_clk);
- if (ret)
- goto assert_reset;
-
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
Hi,
On Sun, May 14, 2023 at 08:46:05PM +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.
>
> Move the place where reset_control_deassert() is called so that the
> recommended order of reset release/clock enable steps is kept.
> A64 manual states that:
>
> 3.3.6.4. Gating and reset
>
> Make sure that the reset signal has been released before the release of
> module clock gating;
>
> This fixes the issue and removes some LoC at the same time.
It should really be three different patches:
- One to fix the resource release, that can be backported to stable
releases
- One to switch to devm_clk_get_enabled
- and one to change the order of clock enable vs reset deassertion
Maxime
Hi Maxime,
On Mon, May 15, 2023 at 01:54:41PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Sun, May 14, 2023 at 08:46:05PM +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.
> >
> > Move the place where reset_control_deassert() is called so that the
> > recommended order of reset release/clock enable steps is kept.
> > A64 manual states that:
> >
> > 3.3.6.4. Gating and reset
> >
> > Make sure that the reset signal has been released before the release of
> > module clock gating;
> >
> > This fixes the issue and removes some LoC at the same time.
>
> It should really be three different patches:
> - One to fix the resource release, that can be backported to stable
> releases
> - One to switch to devm_clk_get_enabled
> - and one to change the order of clock enable vs reset deassertion
The order was correct before this patch. I don't think an incorrect order
should be intorduced, even if temporarily between two patches.
regards,
o.
> Maxime
On 15/05/2023 14:33, Ondřej Jirman wrote:
> Hi Maxime,
>
> On Mon, May 15, 2023 at 01:54:41PM +0200, Maxime Ripard wrote:
>> Hi,
>>
>> On Sun, May 14, 2023 at 08:46:05PM +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.
>>>
>>> Move the place where reset_control_deassert() is called so that the
>>> recommended order of reset release/clock enable steps is kept.
>>> A64 manual states that:
>>>
>>> 3.3.6.4. Gating and reset
>>>
>>> Make sure that the reset signal has been released before the release of
>>> module clock gating;
>>>
>>> This fixes the issue and removes some LoC at the same time.
>>
>> It should really be three different patches:
>> - One to fix the resource release, that can be backported to stable
>> releases
>> - One to switch to devm_clk_get_enabled
>> - and one to change the order of clock enable vs reset deassertion
>
> The order was correct before this patch. I don't think an incorrect order
> should be intorduced, even if temporarily between two patches.
Maxime ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
On Tue, Jun 13, 2023 at 10:49:24AM +0200, Daniel Lezcano wrote:
> On 15/05/2023 14:33, Ondřej Jirman wrote:
> > Hi Maxime,
> >
> > On Mon, May 15, 2023 at 01:54:41PM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Sun, May 14, 2023 at 08:46:05PM +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.
> > > >
> > > > Move the place where reset_control_deassert() is called so that the
> > > > recommended order of reset release/clock enable steps is kept.
> > > > A64 manual states that:
> > > >
> > > > 3.3.6.4. Gating and reset
> > > >
> > > > Make sure that the reset signal has been released before the release of
> > > > module clock gating;
> > > >
> > > > This fixes the issue and removes some LoC at the same time.
> > >
> > > It should really be three different patches:
> > > - One to fix the resource release, that can be backported to stable
> > > releases
> > > - One to switch to devm_clk_get_enabled
> > > - and one to change the order of clock enable vs reset deassertion
> >
> > The order was correct before this patch. I don't think an incorrect order
> > should be intorduced, even if temporarily between two patches.
>
> Maxime ?
I agree with Ondřej
Maxime
On 13/06/2023 11:16, Maxime Ripard wrote:
> On Tue, Jun 13, 2023 at 10:49:24AM +0200, Daniel Lezcano wrote:
>> On 15/05/2023 14:33, Ondřej Jirman wrote:
>>> Hi Maxime,
>>>
>>> On Mon, May 15, 2023 at 01:54:41PM +0200, Maxime Ripard wrote:
>>>> Hi,
>>>>
>>>> On Sun, May 14, 2023 at 08:46:05PM +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.
>>>>>
>>>>> Move the place where reset_control_deassert() is called so that the
>>>>> recommended order of reset release/clock enable steps is kept.
>>>>> A64 manual states that:
>>>>>
>>>>> 3.3.6.4. Gating and reset
>>>>>
>>>>> Make sure that the reset signal has been released before the release of
>>>>> module clock gating;
>>>>>
>>>>> This fixes the issue and removes some LoC at the same time.
>>>>
>>>> It should really be three different patches:
>>>> - One to fix the resource release, that can be backported to stable
>>>> releases
>>>> - One to switch to devm_clk_get_enabled
>>>> - and one to change the order of clock enable vs reset deassertion
>>>
>>> The order was correct before this patch. I don't think an incorrect order
>>> should be intorduced, even if temporarily between two patches.
>>
>> Maxime ?
>
> I agree with Ondřej
Thanks, I applied the patch
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog