| Message ID | 62adddea1fc5e9133766af2d953be7334f4622aa.1638959417.git.geert+renesas@glider.be (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Kieran Bingham |
| Headers | show |
| Series | drm: rcar-du: Use dev_err_probe() helper | expand |
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 >
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
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; > > } > >
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
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 --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; }
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(-)