diff mbox series

drm: rcar-du: Use dev_err_probe() helper

Message ID 62adddea1fc5e9133766af2d953be7334f4622aa.1638959417.git.geert+renesas@glider.be (mailing list archive)
State New, archived
Headers show
Series drm: rcar-du: Use dev_err_probe() helper | expand

Commit Message

Geert Uytterhoeven Dec. 8, 2021, 10:30 a.m. UTC
Use the dev_err_probe() helper, instead of open-coding the same
operation.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Comments

Kieran Bingham Dec. 8, 2021, 11:57 a.m. UTC | #1
Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> Use the dev_err_probe() helper, instead of open-coding the same
> operation.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -661,9 +661,8 @@ static int rcar_du_probe(struct platform_device *pdev)
>         /* DRM/KMS objects */
>         ret = rcar_du_modeset_init(rcdu);
>         if (ret < 0) {
> -               if (ret != -EPROBE_DEFER)
> -                       dev_err(&pdev->dev,
> -                               "failed to initialize DRM/KMS (%d)\n", ret);
> +               dev_err_probe(&pdev->dev, ret,
> +                             "failed to initialize DRM/KMS\n");

I've just learned that dev_err_probe() sets a 'reason' for the deferral.
Seems like a nice feature when exploring devices that are still waiting
to probe. Is the message still appropriate enough in that case?

I think it's probably fine, so

Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>


>                 goto error;
>         }
>  
> -- 
> 2.25.1
>
Geert Uytterhoeven Dec. 8, 2021, 12:25 p.m. UTC | #2
Hi Kieran,

On Wed, Dec 8, 2021 at 12:57 PM Kieran Bingham
<kieran.bingham+renesas@ideasonboard.com> wrote:
> Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > Use the dev_err_probe() helper, instead of open-coding the same
> > operation.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -661,9 +661,8 @@ static int rcar_du_probe(struct platform_device *pdev)
> >         /* DRM/KMS objects */
> >         ret = rcar_du_modeset_init(rcdu);
> >         if (ret < 0) {
> > -               if (ret != -EPROBE_DEFER)
> > -                       dev_err(&pdev->dev,
> > -                               "failed to initialize DRM/KMS (%d)\n", ret);
> > +               dev_err_probe(&pdev->dev, ret,
> > +                             "failed to initialize DRM/KMS\n");
>
> I've just learned that dev_err_probe() sets a 'reason' for the deferral.
> Seems like a nice feature when exploring devices that are still waiting
> to probe. Is the message still appropriate enough in that case?
>
> I think it's probably fine, so

I have no idea why it could fail. So if you think the message is
fine, it must be fine ;-)

> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>

Thanks!

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
Laurent Pinchart Dec. 8, 2021, 5:59 p.m. UTC | #3
Hello,

On Wed, Dec 08, 2021 at 11:57:21AM +0000, Kieran Bingham wrote:
> Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > Use the dev_err_probe() helper, instead of open-coding the same
> > operation.
> > 
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -661,9 +661,8 @@ static int rcar_du_probe(struct platform_device *pdev)
> >         /* DRM/KMS objects */
> >         ret = rcar_du_modeset_init(rcdu);
> >         if (ret < 0) {
> > -               if (ret != -EPROBE_DEFER)
> > -                       dev_err(&pdev->dev,
> > -                               "failed to initialize DRM/KMS (%d)\n", ret);
> > +               dev_err_probe(&pdev->dev, ret,
> > +                             "failed to initialize DRM/KMS\n");
> 
> I've just learned that dev_err_probe() sets a 'reason' for the deferral.
> Seems like a nice feature when exploring devices that are still waiting
> to probe. Is the message still appropriate enough in that case?

It's a very generic message, so it's not ideal. One issue is that
dev_err_probe() replaces any currently stored probe deferral reason
message, which means that we'll override any message previously set. We
don't set any message now, but we should (in rcar_du_encoder_init(),
there are two main code paths where -EPROBE_DEFER is expected), so this
patch would then get in the way I'm afraid.

> I think it's probably fine, so
> 
> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> 
> >                 goto error;
> >         }
> >
Geert Uytterhoeven Dec. 8, 2021, 6:23 p.m. UTC | #4
Hi Laurent,

On Wed, Dec 8, 2021 at 7:00 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wed, Dec 08, 2021 at 11:57:21AM +0000, Kieran Bingham wrote:
> > Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > > Use the dev_err_probe() helper, instead of open-coding the same
> > > operation.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > ---
> > >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
> > > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > @@ -661,9 +661,8 @@ static int rcar_du_probe(struct platform_device *pdev)
> > >         /* DRM/KMS objects */
> > >         ret = rcar_du_modeset_init(rcdu);
> > >         if (ret < 0) {
> > > -               if (ret != -EPROBE_DEFER)
> > > -                       dev_err(&pdev->dev,
> > > -                               "failed to initialize DRM/KMS (%d)\n", ret);
> > > +               dev_err_probe(&pdev->dev, ret,
> > > +                             "failed to initialize DRM/KMS\n");
> >
> > I've just learned that dev_err_probe() sets a 'reason' for the deferral.
> > Seems like a nice feature when exploring devices that are still waiting
> > to probe. Is the message still appropriate enough in that case?
>
> It's a very generic message, so it's not ideal. One issue is that
> dev_err_probe() replaces any currently stored probe deferral reason
> message, which means that we'll override any message previously set. We
> don't set any message now, but we should (in rcar_du_encoder_init(),
> there are two main code paths where -EPROBE_DEFER is expected), so this
> patch would then get in the way I'm afraid.

If rcar_du_encoder_init() will handle the printing of errors, there is indeed
no more reason for rcar_du_probe() to do that, so the existing dev_err()
with the fuzzy message can be removed?

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
Laurent Pinchart Dec. 8, 2021, 6:59 p.m. UTC | #5
Hi Geert,

On Wed, Dec 08, 2021 at 07:23:25PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 8, 2021 at 7:00 PM Laurent Pinchart wrote:
> > On Wed, Dec 08, 2021 at 11:57:21AM +0000, Kieran Bingham wrote:
> > > Quoting Geert Uytterhoeven (2021-12-08 10:30:53)
> > > > Use the dev_err_probe() helper, instead of open-coding the same
> > > > operation.
> > > >
> > > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > > > ---
> > > >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 5 ++---
> > > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > > index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
> > > > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > > > @@ -661,9 +661,8 @@ static int rcar_du_probe(struct platform_device *pdev)
> > > >         /* DRM/KMS objects */
> > > >         ret = rcar_du_modeset_init(rcdu);
> > > >         if (ret < 0) {
> > > > -               if (ret != -EPROBE_DEFER)
> > > > -                       dev_err(&pdev->dev,
> > > > -                               "failed to initialize DRM/KMS (%d)\n", ret);
> > > > +               dev_err_probe(&pdev->dev, ret,
> > > > +                             "failed to initialize DRM/KMS\n");
> > >
> > > I've just learned that dev_err_probe() sets a 'reason' for the deferral.
> > > Seems like a nice feature when exploring devices that are still waiting
> > > to probe. Is the message still appropriate enough in that case?
> >
> > It's a very generic message, so it's not ideal. One issue is that
> > dev_err_probe() replaces any currently stored probe deferral reason
> > message, which means that we'll override any message previously set. We
> > don't set any message now, but we should (in rcar_du_encoder_init(),
> > there are two main code paths where -EPROBE_DEFER is expected), so this
> > patch would then get in the way I'm afraid.
> 
> If rcar_du_encoder_init() will handle the printing of errors, there is indeed
> no more reason for rcar_du_probe() to do that, so the existing dev_err()
> with the fuzzy message can be removed?

We could drop the above message indeed, at least once all the error
paths deeper in the call stack will print a detailed message. The
message here is useful in case an error path forgets to print anything,
to avoid the worst case of probe() failing silently.
diff mbox series

Patch

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 5612a9e7a9056cf7..86eeda769e2ebd10 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -661,9 +661,8 @@  static int rcar_du_probe(struct platform_device *pdev)
 	/* DRM/KMS objects */
 	ret = rcar_du_modeset_init(rcdu);
 	if (ret < 0) {
-		if (ret != -EPROBE_DEFER)
-			dev_err(&pdev->dev,
-				"failed to initialize DRM/KMS (%d)\n", ret);
+		dev_err_probe(&pdev->dev, ret,
+			      "failed to initialize DRM/KMS\n");
 		goto error;
 	}