linux-kernel - Re: [PATCH v3 3/4] staging: fbtft: Don't spam logs when probe is deferred

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: <20210429154002.GF21598@kadam>
Date:   Thu, 29 Apr 2021 18:40:02 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Phil Reid <preid@...ctromag.com.au>,
        dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
        linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v3 3/4] staging: fbtft: Don't spam logs when probe is
 deferred

On Thu, Apr 29, 2021 at 05:42:44PM +0300, Dan Carpenter wrote:
> On Wed, Apr 28, 2021 at 04:04:14PM +0300, Andy Shevchenko wrote:
> > @@ -75,20 +75,16 @@ static int fbtft_request_one_gpio(struct fbtft_par *par,
> >  				  struct gpio_desc **gpiop)
> >  {
> >  	struct device *dev = par->info->device;
> > -	int ret = 0;
> >  
> >  	*gpiop = devm_gpiod_get_index_optional(dev, name, index,
> >  					       GPIOD_OUT_LOW);
> > -	if (IS_ERR(*gpiop)) {
> > -		ret = PTR_ERR(*gpiop);
> > -		dev_err(dev,
> > -			"Failed to request %s GPIO: %d\n", name, ret);
> > -		return ret;
> > -	}
> > +	if (IS_ERR(*gpiop))
> > +		dev_err_probe(dev, PTR_ERR(*gpiop), "Failed to request %s GPIO\n", name);
> 
> This should be a return statement:
> 
> 		return dev_err_probe(dev, PTR_ERR(*gpiop), "Failed to request %s GPIO\n", name);
> 

I've created a new Smatch check for these:

drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c:2890 mcp251xfd_probe() warn: pointer error 'PTR_ERR(clk)' not handled

There aren't that many bugs...  Anyway, I'm running a test now and I
guess we'll see tomorrow how it goes.

regards,
dan carpenter