[v2] thermal/drivers/sun8i: Fix some error handling paths in sun8i_ths_probe()

Message ID a8ae84bd2dc4b55fe428f8e20f31438bf8bb6762.1684089931.git.christophe.jaillet@wanadoo.fr
State New
Headers
Series [v2] thermal/drivers/sun8i: Fix some error handling paths in sun8i_ths_probe() |

Commit Message

Christophe JAILLET May 14, 2023, 6:46 p.m. UTC
  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 <christophe.jaillet@wanadoo.fr>
---
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(-)
  

Comments

Maxime Ripard May 15, 2023, 11:54 a.m. UTC | #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
  
Ondřej Jirman May 15, 2023, 12:33 p.m. UTC | #2
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
  
Daniel Lezcano June 13, 2023, 8:49 a.m. UTC | #3
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 ?
  
Maxime Ripard June 13, 2023, 9:16 a.m. UTC | #4
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
  
Daniel Lezcano June 13, 2023, 9:17 a.m. UTC | #5
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
  

Patch

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,