2021-04-28 14:52:42

by Andy Shevchenko

Subject: [PATCH v3 3/4] staging: fbtft: Don't spam logs when probe is deferred

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 <[email protected]>
---
drivers/staging/fbtft/fbtft-core.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)

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)
--
2.30.2

2021-04-29 14:44:31

by Dan Carpenter

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

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

2021-04-29 15:43:02

by Dan Carpenter

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

2021-04-29 16:58:05

by Andy Shevchenko

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:

> > + 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 :-(


--
With Best Regards,
Andy Shevchenko