From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON Date: Thu, 17 May 2018 16:55:05 +0200 Message-ID: <20180517145505.GI26515@ulmo> References: <20180330141138.28987-1-daniels@collabora.com> <20180330141138.28987-8-daniels@collabora.com> <20180517135819.GG3373@art_vandelay> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0205581863==" Return-path: Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6AA446E94C for ; Thu, 17 May 2018 14:55:09 +0000 (UTC) Received: by mail-wr0-x243.google.com with SMTP id v60-v6so6008552wrc.7 for ; Thu, 17 May 2018 07:55:09 -0700 (PDT) In-Reply-To: <20180517135819.GG3373@art_vandelay> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Sean Paul Cc: Daniel Stone , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0205581863== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vs0rQTeTompTJjtd" Content-Disposition: inline --vs0rQTeTompTJjtd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 17, 2018 at 09:58:19AM -0400, Sean Paul wrote: > On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote: > > A FB with no object is something we should be shouting very loudly > > about, not quietly logging as debug. > >=20 > > Signed-off-by: Daniel Stone > > Cc: CK Hu > > Cc: Philipp Zabel > > --- > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +---- > > 1 file changed, 1 insertion(+), 4 deletions(-) > >=20 > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm= /mediatek/mtk_drm_plane.c > > index 2f4b0ffee598..ac010365d88b 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c > > @@ -95,10 +95,7 @@ static int mtk_plane_atomic_check(struct drm_plane *= plane, > > if (!fb) > > return 0; > > =20 > > - if (!mtk_fb_get_gem_obj(fb)) { > > - DRM_DEBUG_KMS("buffer is null\n"); > > - return -EFAULT; > > - } > > + WARN_ON(!mtk_fb_get_gem_obj(fb)); >=20 > We should presumably still bail out with an error, no? I think we should just remove this WARN_ON(). Under what circumstances would this case even happen? If the GEM object for a framebuffer doesn't exist, then mtk_drm_mode_fb_create() will fail and no pointer to struct drm_framebuffer will ever be returned. After that, the GEM object is guaranteed to be there, so the above is effectively dead code. Thierry --vs0rQTeTompTJjtd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlr9l8kACgkQ3SOs138+ s6H9cxAAh48GNNw1CVGr24x87Pddpw+enEcJ/x9TjT1O6SHTx/8uInKfUkhfjGZl N1h1B7Rsv16DJqP+bQs8oc8VEMcZUvFtuvAiVjl5zoHgkScy70lLAlGSajiHJ4If Gek5hSgaDJweV1jxBUbFvbwb5KFbXXm0DHM6wrbm3ZJ1NRQ4WF1lchwUiZM0h+E4 kaScOGD/+6hchg5EzdC5+GPpOt9lCBgKNaLoK50AYxmcRpurt53hcM7RzJgH/nhS 884DeWnondPBQpu0836wwR6qAxff3lFk4vzr5Rek2PeWEsYjc/SijrNIAuyFg2GY tw2Tj4btUnk7PTeOihZM87lmYpLOy9V0NxT9OlZtqix8aRyUamoPbP0c8GzMigw0 7NTPFkgQNt/eP8TOWWe4XWEvbNEjZCAXouERrU0donPi2aocKtQkb7g2AVHWGw/3 sN72LhrZCLoK+tOS4pRqN2VUjD338oc/XJjlFBgEVohueQsqsMVvCJN/LFRZwx3L ohqID2Ni71arKC6JYOVQQwC/d6z1eANr7gtCHs0ZkNH4nXTD1p6SLVVq2SIiprI+ HUb/RnRITd/fRoVZtXZEJfewcqJz5z8c28xlIC54Kr4UEj+xArbuf3X++iB3gnw1 /Ff8QOOQACyX0N1py0oxfkK5doygr4E+YGOO/s59YF5plsamN4M= =BIs5 -----END PGP SIGNATURE----- --vs0rQTeTompTJjtd-- --===============0205581863== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0205581863==--