linux-kernel - Re: [PATCH] drm: rcar-du: EPROBE_DEFER case doesn't need error message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3209827.hXSB4Y22Yy@avalon>
Date:	Tue, 24 May 2016 16:32:13 +0300
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc:	David Airlie <airlied@...ux.ie>, dri-devel@...ts.freedesktop.org,
	linux-renesas-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	koji.matsuoka.xm@...esas.com, yoshihiro.shimoda.uh@...esas.com,
	naoya.shiiba.nx@...esas.com, ryo.kodama.vz@...esas.com,
	hiroyuki.yokoyama.vx@...esas.com, yoshifumi.hosoya.wj@...esas.com,
	takeshi.kihara.df@...esas.com, toshiaki.komatsu.ud@...esas.com,
	harunobu.kurokawa.dn@...esas.com, ryusuke.sakato.bx@...esas.com,
	tomoharu.fukawa.eb@...esas.com, kouei.abe.cp@...esas.com,
	khiem.nguyen.xt@....renesas.com, hien.dang.eb@....renesas.com
Subject: Re: [PATCH] drm: rcar-du: EPROBE_DEFER case doesn't need error message

Hi Morimoto-san,

Thank you for the patch.

On Tuesday 24 May 2016 14:24:09 Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
> 
> EPROBE_DEFER is not error, thus, error message on kernel log on this
> case is confusable for user. Prints it only error cases.
> 
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 26fd3ba..1db080c 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -354,14 +354,16 @@ static int rcar_du_probe(struct platform_device *pdev)
> */
>  	ret = drm_vblank_init(ddev, (1 << rcdu->info->num_crtcs) - 1);
>  	if (ret < 0) {
> -		dev_err(&pdev->dev, "failed to initialize vblank\n");
> +		if (ret != -EPROBE_DEFER)

I don't think this can ever happen. Actually, the only reason 
drm_vblank_init() could return an error at the moment is a kcalloc() failure, 
so we could remove this message completely.

> +			dev_err(&pdev->dev, "failed to initialize vblank\n");
>  		goto error;
>  	}
> 
>  	/* DRM/KMS objects */
>  	ret = rcar_du_modeset_init(rcdu);
>  	if (ret < 0) {
> -		dev_err(&pdev->dev, "failed to initialize DRM/KMS (%d)\n", ret);
> +		if (ret != -EPROBE_DEFER)
> +			dev_err(&pdev->dev, "failed to initialize DRM/KMS (%d)\n", ret);
>  		goto error;
>  	}

-- 
Regards,

Laurent Pinchart