| Message ID | 20210428130415.55406-4-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | staging: fbtft: Fixing GPIO handling issues | expand |
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); > + > fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n", > __func__, name); > > - return ret; > + return 0; > } regards, dan carpenter
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
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: > > + 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); Thanks! Funny that I have trapped to this and my patch that adds __must_check to avoid exactly this situations had been reverted :-(
diff --git a/drivers/staging/fbtft/fbtft-core.c b/drivers/staging/fbtft/fbtft-core.c index 67c3b1975a4d..a564907c4fa1 100644 --- a/drivers/staging/fbtft/fbtft-core.c +++ b/drivers/staging/fbtft/fbtft-core.c @@ -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); + fbtft_par_dbg(DEBUG_REQUEST_GPIOS, par, "%s: '%s' GPIO\n", __func__, name); - return ret; + return 0; } static int fbtft_request_gpios(struct fbtft_par *par)
When requesting GPIO line the probe can be deferred. In such case don't spam logs with an error message. This can be achieved by switching to dev_err_probe(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> --- drivers/staging/fbtft/fbtft-core.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)