pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <[email protected]>
---
drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c
index c650e45bb0ad..017a54f2fdd8 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -846,8 +846,10 @@ static int vsp1_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
ret = pm_runtime_get_sync(&pdev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_sync(&pdev->dev);
goto done;
+ }
vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
pm_runtime_put_sync(&pdev->dev);
--
2.17.1
Hi Dinghao,
Thank you for the patch.
On Sat, May 23, 2020 at 07:54:26PM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
I wonder how many bugs we have today, and how many bugs will keep
appearing in the future, due to this historical design mistake :-(
> Signed-off-by: Dinghao Liu <[email protected]>
> ---
> drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c
> index c650e45bb0ad..017a54f2fdd8 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -846,8 +846,10 @@ static int vsp1_probe(struct platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
>
> ret = pm_runtime_get_sync(&pdev->dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_sync(&pdev->dev);
> goto done;
> + }
This change looks good to me, but we also need a similar change in the
vsp1_device_get() function if I'm not mistaken. Could you combine both
in the same patch ?
>
> vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
> pm_runtime_put_sync(&pdev->dev);
--
Regards,
Laurent Pinchart
On Mon, Jun 08, 2020 at 04:54:57AM +0300, Laurent Pinchart wrote:
> Hi Dinghao,
>
> Thank you for the patch.
>
> On Sat, May 23, 2020 at 07:54:26PM +0800, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > when it returns an error code. Thus a pairing decrement is needed on
> > the error handling path to keep the counter balanced.
>
> I wonder how many bugs we have today, and how many bugs will keep
> appearing in the future, due to this historical design mistake :-(
>
> > Signed-off-by: Dinghao Liu <[email protected]>
> > ---
> > drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c
> > index c650e45bb0ad..017a54f2fdd8 100644
> > --- a/drivers/media/platform/vsp1/vsp1_drv.c
> > +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> > @@ -846,8 +846,10 @@ static int vsp1_probe(struct platform_device *pdev)
> > pm_runtime_enable(&pdev->dev);
> >
> > ret = pm_runtime_get_sync(&pdev->dev);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + pm_runtime_put_sync(&pdev->dev);
> > goto done;
> > + }
>
> This change looks good to me, but we also need a similar change in the
> vsp1_device_get() function if I'm not mistaken. Could you combine both
> in the same patch ?
And actually, after fixing vsp1_device_get(), we should replace the
pm_runtime_get_sync() call here with vsp1_device_get(), and the
pm_runtime_put_sync() below with vsp1_device_put(), so there would be no
need to call pm_runtime_put_sync() manually in the error path here.
> >
> > vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
> > pm_runtime_put_sync(&pdev->dev);
--
Regards,
Laurent Pinchart
Hi Laurent,
> >
> > I wonder how many bugs we have today, and how many bugs will keep
> > appearing in the future, due to this historical design mistake :-(
> >
Good question. It's hard to say if this is a design mistake (some use
of this API does not check its return value and expects it always to
increment the usage counter). But it does make developers misuse it easier.
> >
> > This change looks good to me, but we also need a similar change in the
> > vsp1_device_get() function if I'm not mistaken. Could you combine both
> > in the same patch ?
>
Thank you for your advice! I think you are right and I will fix this in the
next version of patch.
> And actually, after fixing vsp1_device_get(), we should replace the
> pm_runtime_get_sync() call here with vsp1_device_get(), and the
> pm_runtime_put_sync() below with vsp1_device_put(), so there would be no
> need to call pm_runtime_put_sync() manually in the error path here.
>
The parameter type of vsp1_device_get() and vsp1_device_put() is "struct
vsp1_device". If we want to use these two wrappers, we need to adjust their
parameter type to "struct platform_device" or "struct device", which may
lead to errors in other callers. Maybe we should leave it as it is.
Regards,
Dinghao
Hi Dianghao,
On Mon, Jun 08, 2020 at 11:03:26AM +0800, [email protected] wrote:
> Hi Laurent,
>
> > > I wonder how many bugs we have today, and how many bugs will keep
> > > appearing in the future, due to this historical design mistake :-(
>
> Good question. It's hard to say if this is a design mistake (some use
> of this API does not check its return value and expects it always to
> increment the usage counter). But it does make developers misuse it easier.
>
> > > This change looks good to me, but we also need a similar change in the
> > > vsp1_device_get() function if I'm not mistaken. Could you combine both
> > > in the same patch ?
>
> Thank you for your advice! I think you are right and I will fix this in the
> next version of patch.
>
> > And actually, after fixing vsp1_device_get(), we should replace the
> > pm_runtime_get_sync() call here with vsp1_device_get(), and the
> > pm_runtime_put_sync() below with vsp1_device_put(), so there would be no
> > need to call pm_runtime_put_sync() manually in the error path here.
>
> The parameter type of vsp1_device_get() and vsp1_device_put() is "struct
> vsp1_device". If we want to use these two wrappers, we need to adjust their
> parameter type to "struct platform_device" or "struct device", which may
> lead to errors in other callers. Maybe we should leave it as it is.
The vsp1_probe() function has a struct vsp1_device whose dev field is
populated by the time it needs to call pm_runtime_get_sync() and
pm_runtime_get_put(), so I think you can use vsp1_device_get() and
vsp1_device_put() as drop-in replacements without changing the
parameters to these two functions.
--
Regards,
Laurent Pinchart
>
> The vsp1_probe() function has a struct vsp1_device whose dev field is
> populated by the time it needs to call pm_runtime_get_sync() and
> pm_runtime_get_put(), so I think you can use vsp1_device_get() and
> vsp1_device_put() as drop-in replacements without changing the
> parameters to these two functions.
>
It's clear to me, thanks!
Regards,
Dinghao
Hi Dinghao,
On Mon, Jun 8, 2020 at 5:03 AM <[email protected]> wrote:
> > > I wonder how many bugs we have today, and how many bugs will keep
> > > appearing in the future, due to this historical design mistake :-(
>
> Good question. It's hard to say if this is a design mistake (some use
> of this API does not check its return value and expects it always to
> increment the usage counter). But it does make developers misuse it easier.
On Renesas SoCs, I believe these can only fail if there's something
seriously wrong, which means the system could never have gotten this far
in the boot sequence anyway. That's why I tend not to check the result
of pm_runtime_get_sync() at all (on drivers for Renesas SoCs).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
On Mon, Jun 08, 2020 at 09:39:51AM +0200, Geert Uytterhoeven wrote:
> Hi Dinghao,
>
> On Mon, Jun 8, 2020 at 5:03 AM <[email protected]> wrote:
> > > > I wonder how many bugs we have today, and how many bugs will keep
> > > > appearing in the future, due to this historical design mistake :-(
> >
> > Good question. It's hard to say if this is a design mistake (some use
> > of this API does not check its return value and expects it always to
> > increment the usage counter). But it does make developers misuse it easier.
>
> On Renesas SoCs, I believe these can only fail if there's something
> seriously wrong, which means the system could never have gotten this far
> in the boot sequence anyway. That's why I tend not to check the result
> of pm_runtime_get_sync() at all (on drivers for Renesas SoCs).
There are lots of return paths from rpm_resume() that return an error,
more than just rpm_callback(). Do you consider that none of them are
valid errors that drivers need to handle ?
--
Regards,
Laurent Pinchart