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