| Message ID | e39752476d02605b2be46cab7115f71255ce13a8.1668949256.git.christophe.jaillet@wanadoo.fr (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [1/2] mfd: qcom_rpm: Fix an error handling path in qcom_rpm_probe() | expand |
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
diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c index 71bc34b74bc9..ea5eb94427c4 100644 --- a/drivers/mfd/qcom_rpm.c +++ b/drivers/mfd/qcom_rpm.c @@ -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; }
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(-)