From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932611AbcA2RqX (ORCPT ); Fri, 29 Jan 2016 12:46:23 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:35830 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751753AbcA2RqU (ORCPT ); Fri, 29 Jan 2016 12:46:20 -0500 Date: Fri, 29 Jan 2016 17:46:02 +0000 From: One Thousand Gnomes To: Insu Yun Cc: patrik.r.jakobsson@gmail.com, airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, taesoo@gatech.edu, yeongjin.jang@gatech.edu, insu@gatech.edu, changwoo@gatech.edu Subject: Re: [PATCH] gma500: handling failed allocation Message-ID: <20160129174602.7818a35a@lxorguk.ukuu.org.uk> In-Reply-To: <1454025916-5218-1-git-send-email-wuninsu@gmail.com> References: <1454025916-5218-1-git-send-email-wuninsu@gmail.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 28 Jan 2016 19:05:16 -0500 Insu Yun wrote: > Since drm_property_create_range can be failed in memory pressure, > it needs to be handled. > > Signed-off-by: Insu Yun > --- > drivers/gpu/drm/gma500/framebuffer.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c > index cb95765..31085e4 100644 > --- a/drivers/gpu/drm/gma500/framebuffer.c > +++ b/drivers/gpu/drm/gma500/framebuffer.c > @@ -683,6 +683,8 @@ static int psb_create_backlight_property(struct drm_device *dev) > return 0; > > backlight = drm_property_create_range(dev, 0, "backlight", 0, 100); > + if (!backlight) > + return -ENOMEM; > > dev_priv->backlight_property = backlight; > NAK. If we fail to create the backlight we are better off continuing than failing. The user just loses backlight control rather than having no display at all. If you check the callers you'll notice that the only caller doesn't even check the return code anyway so your patch is a no-op. If you are going to add error checking to anything with a patch please work back through the call chain and check the effect of the new error return - if any. A better patch I think would be to just eliminate the function and turn it into a tiny bit of inlined code. I'll send a patch to do that shortly. Alan