2019-11-04 15:53:06

by Chuhong Yuan

Subject: [PATCH] media: exynos4-is: add missed clk_disable_unprepare in remove

This driver forgets to disable and unprepare clock when remove.
Add a call to clk_disable_unprepare to fix it.

Signed-off-by: Chuhong Yuan <[email protected]>
---
drivers/media/platform/exynos4-is/fimc-lite.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
index e87c6a09205b..6748bd96aada 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -1614,6 +1614,7 @@ static int fimc_lite_remove(struct platform_device *pdev)
struct fimc_lite *fimc = platform_get_drvdata(pdev);
struct device *dev = &pdev->dev;

+ clk_disable_unprepare(fimc->clock);
pm_runtime_disable(dev);
pm_runtime_set_suspended(dev);
fimc_lite_unregister_capture_subdev(fimc);
--
2.23.0

2019-12-12 10:40:42

by Hans Verkuil

Subject: Re: [PATCH] media: exynos4-is: add missed clk_disable_unprepare in remove

On 11/4/19 4:49 PM, Chuhong Yuan wrote:
> This driver forgets to disable and unprepare clock when remove.
> Add a call to clk_disable_unprepare to fix it.

I'd like an Ack from Samsung before I apply this. I see this in the probe() in fimc-lite.c:

if (!pm_runtime_enabled(dev)) {
ret = clk_prepare_enable(fimc->clock);
if (ret < 0)
goto err_sd;
}

So is it right to always call clk_disable_unprepare in the remove()?

I suspect it is correct, but I would like someone else to take a look as well.

Regards,

Hans

>
> Signed-off-by: Chuhong Yuan <[email protected]>
> ---
> drivers/media/platform/exynos4-is/fimc-lite.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
> index e87c6a09205b..6748bd96aada 100644
> --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> @@ -1614,6 +1614,7 @@ static int fimc_lite_remove(struct platform_device *pdev)
> struct fimc_lite *fimc = platform_get_drvdata(pdev);
> struct device *dev = &pdev->dev;
>
> + clk_disable_unprepare(fimc->clock);
> pm_runtime_disable(dev);
> pm_runtime_set_suspended(dev);
> fimc_lite_unregister_capture_subdev(fimc);
>

2019-12-12 11:04:53

by Krzysztof Kozlowski

Subject: Re: [PATCH] media: exynos4-is: add missed clk_disable_unprepare in remove

On Thu, 12 Dec 2019 at 11:39, Hans Verkuil <[email protected]> wrote:
>
> On 11/4/19 4:49 PM, Chuhong Yuan wrote:
> > This driver forgets to disable and unprepare clock when remove.
> > Add a call to clk_disable_unprepare to fix it.
>
> I'd like an Ack from Samsung before I apply this. I see this in the probe() in fimc-lite.c:
>
> if (!pm_runtime_enabled(dev)) {
> ret = clk_prepare_enable(fimc->clock);
> if (ret < 0)
> goto err_sd;
> }
>
> So is it right to always call clk_disable_unprepare in the remove()?
>
> I suspect it is correct, but I would like someone else to take a look as well.
>
> Regards,
>
> Hans
>
> >
> > Signed-off-by: Chuhong Yuan <[email protected]>
> > ---
> > drivers/media/platform/exynos4-is/fimc-lite.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
> > index e87c6a09205b..6748bd96aada 100644
> > --- a/drivers/media/platform/exynos4-is/fimc-lite.c
> > +++ b/drivers/media/platform/exynos4-is/fimc-lite.c
> > @@ -1614,6 +1614,7 @@ static int fimc_lite_remove(struct platform_device *pdev)
> > struct fimc_lite *fimc = platform_get_drvdata(pdev);
> > struct device *dev = &pdev->dev;
> >
> > + clk_disable_unprepare(fimc->clock);
> > pm_runtime_disable(dev);
> > pm_runtime_set_suspended(dev);
> > fimc_lite_unregister_capture_subdev(fimc);

No, it is wrong. The clock is enabled in probe only if
!pm_runtime_enabled(). This will matter only if PM is disabled but now
it leads to unbalanced disables. This was clearly not tested because I
believe any test would trigger error. In such case, please mark the
patches as RFT.

There is some tendency to post small "fixes" like this without
testing... ok, not everyone has hardware but then just mark it as
not-tested or RFT...

Best regards,
Krzysztof