[1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe()
Commit Message
If an error occurs after the clk_prepare_enable() call, a corresponding
clk_disable_unprepare() should be called.
Simplify code and switch to devm_clk_get_enabled() to fix it.
Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This changes the order of the clean-ups if the .remove() function is called
but it looks fine to me.
---
drivers/mfd/qcom_rpm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Comments
On Sun, 20 Nov 2022, Christophe JAILLET wrote:
> If an error occurs after the clk_prepare_enable() call, a corresponding
> clk_disable_unprepare() should be called.
>
> Simplify code and switch to devm_clk_get_enabled() to fix it.
>
> Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This changes the order of the clean-ups if the .remove() function is called
> but it looks fine to me.
> ---
> drivers/mfd/qcom_rpm.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Something funny going on here.
I received 3 identical versions of the same patch.
On Sun, 20 Nov 2022, Christophe JAILLET wrote:
> If an error occurs after the clk_prepare_enable() call, a corresponding
> clk_disable_unprepare() should be called.
>
> Simplify code and switch to devm_clk_get_enabled() to fix it.
>
> Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> This changes the order of the clean-ups if the .remove() function is called
> but it looks fine to me.
> ---
> drivers/mfd/qcom_rpm.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Applied, thanks.
Le 08/12/2022 à 13:30, Lee Jones a écrit :
> On Sun, 20 Nov 2022, Christophe JAILLET wrote:
>
>> If an error occurs after the clk_prepare_enable() call, a corresponding
>> clk_disable_unprepare() should be called.
>>
>> Simplify code and switch to devm_clk_get_enabled() to fix it.
>>
>> Fixes: 3526403353c2 ("mfd: qcom_rpm: Handle message RAM clock")
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> This changes the order of the clean-ups if the .remove() function is called
>> but it looks fine to me.
>> ---
>> drivers/mfd/qcom_rpm.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> Something funny going on here.
>
> I received 3 identical versions of the same patch.
>
Yes, was my fault.
Sorry for the inconvenience.
CJ
@@ -547,7 +547,7 @@ static int qcom_rpm_probe(struct platform_device *pdev)
init_completion(&rpm->ack);
/* Enable message RAM clock */
- rpm->ramclk = devm_clk_get(&pdev->dev, "ram");
+ rpm->ramclk = devm_clk_get_enabled(&pdev->dev, "ram");
if (IS_ERR(rpm->ramclk)) {
ret = PTR_ERR(rpm->ramclk);
if (ret == -EPROBE_DEFER)
@@ -558,7 +558,6 @@ static int qcom_rpm_probe(struct platform_device *pdev)
*/
rpm->ramclk = NULL;
}
- clk_prepare_enable(rpm->ramclk); /* Accepts NULL */
irq_ack = platform_get_irq_byname(pdev, "ack");
if (irq_ack < 0)
@@ -681,7 +680,6 @@ static int qcom_rpm_remove(struct platform_device *pdev)
struct qcom_rpm *rpm = dev_get_drvdata(&pdev->dev);
of_platform_depopulate(&pdev->dev);
- clk_disable_unprepare(rpm->ramclk);
return 0;
}