* [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
@ 2020-05-23 11:54 Dinghao Liu
2020-06-08 1:54 ` Laurent Pinchart
0 siblings, 1 reply; 8+ messages in thread
From: Dinghao Liu @ 2020-05-23 11:54 UTC (permalink / raw)
To: dinghao.liu, kjlu
Cc: Laurent Pinchart, Kieran Bingham, Mauro Carvalho Chehab,
linux-media, linux-renesas-soc, linux-kernel
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 <dinghao.liu@zju.edu.cn>
---
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
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-05-23 11:54 [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe Dinghao Liu
@ 2020-06-08 1:54 ` Laurent Pinchart
2020-06-08 1:57 ` Laurent Pinchart
0 siblings, 1 reply; 8+ messages in thread
From: Laurent Pinchart @ 2020-06-08 1:54 UTC (permalink / raw)
To: Dinghao Liu
Cc: kjlu, Kieran Bingham, Mauro Carvalho Chehab, linux-media,
linux-renesas-soc, linux-kernel
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 <dinghao.liu@zju.edu.cn>
> ---
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-06-08 1:54 ` Laurent Pinchart
@ 2020-06-08 1:57 ` Laurent Pinchart
2020-06-08 3:03 ` dinghao.liu
0 siblings, 1 reply; 8+ messages in thread
From: Laurent Pinchart @ 2020-06-08 1:57 UTC (permalink / raw)
To: Dinghao Liu
Cc: kjlu, Kieran Bingham, Mauro Carvalho Chehab, linux-media,
linux-renesas-soc, linux-kernel
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 <dinghao.liu@zju.edu.cn>
> > ---
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-06-08 1:57 ` Laurent Pinchart
@ 2020-06-08 3:03 ` dinghao.liu
2020-06-08 3:11 ` Laurent Pinchart
2020-06-08 7:39 ` Geert Uytterhoeven
0 siblings, 2 replies; 8+ messages in thread
From: dinghao.liu @ 2020-06-08 3:03 UTC (permalink / raw)
To: Laurent Pinchart
Cc: kjlu, Kieran Bingham, Mauro Carvalho Chehab, linux-media,
linux-renesas-soc, linux-kernel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-06-08 3:03 ` dinghao.liu
@ 2020-06-08 3:11 ` Laurent Pinchart
2020-06-08 3:33 ` dinghao.liu
2020-06-08 7:39 ` Geert Uytterhoeven
1 sibling, 1 reply; 8+ messages in thread
From: Laurent Pinchart @ 2020-06-08 3:11 UTC (permalink / raw)
To: dinghao.liu
Cc: kjlu, Kieran Bingham, Mauro Carvalho Chehab, linux-media,
linux-renesas-soc, linux-kernel
Hi Dianghao,
On Mon, Jun 08, 2020 at 11:03:26AM +0800, dinghao.liu@zju.edu.cn 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-06-08 3:11 ` Laurent Pinchart
@ 2020-06-08 3:33 ` dinghao.liu
0 siblings, 0 replies; 8+ messages in thread
From: dinghao.liu @ 2020-06-08 3:33 UTC (permalink / raw)
To: Laurent Pinchart
Cc: kjlu, Kieran Bingham, Mauro Carvalho Chehab, linux-media,
linux-renesas-soc, linux-kernel
>
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-06-08 3:03 ` dinghao.liu
2020-06-08 3:11 ` Laurent Pinchart
@ 2020-06-08 7:39 ` Geert Uytterhoeven
2020-06-08 11:54 ` Laurent Pinchart
1 sibling, 1 reply; 8+ messages in thread
From: Geert Uytterhoeven @ 2020-06-08 7:39 UTC (permalink / raw)
To: dinghao.liu
Cc: Laurent Pinchart, Kangjie Lu, Kieran Bingham,
Mauro Carvalho Chehab, Linux Media Mailing List, Linux-Renesas,
Linux Kernel Mailing List
Hi Dinghao,
On Mon, Jun 8, 2020 at 5:03 AM <dinghao.liu@zju.edu.cn> 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 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe
2020-06-08 7:39 ` Geert Uytterhoeven
@ 2020-06-08 11:54 ` Laurent Pinchart
0 siblings, 0 replies; 8+ messages in thread
From: Laurent Pinchart @ 2020-06-08 11:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: dinghao.liu, Kangjie Lu, Kieran Bingham, Mauro Carvalho Chehab,
Linux Media Mailing List, Linux-Renesas,
Linux Kernel Mailing List
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 <dinghao.liu@zju.edu.cn> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-06-08 11:55 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-23 11:54 [PATCH] media: vsp1: Fix runtime PM imbalance in vsp1_probe Dinghao Liu
2020-06-08 1:54 ` Laurent Pinchart
2020-06-08 1:57 ` Laurent Pinchart
2020-06-08 3:03 ` dinghao.liu
2020-06-08 3:11 ` Laurent Pinchart
2020-06-08 3:33 ` dinghao.liu
2020-06-08 7:39 ` Geert Uytterhoeven
2020-06-08 11:54 ` Laurent Pinchart
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).