[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 May 2013 17:18:55 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Srinidhi Kasagar <srinidhi.kasagar@...ricsson.com>
Cc: Lee Jones <lee.jones@...aro.org>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
Linus WALLEIJ <linus.walleij@...ricsson.com>,
"arnd@...db.de" <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 4/4] staging: ste_rmi4: Suppress 'ignoring return value of ‘regulator_enable()' warning
On Fri, May 03, 2013 at 12:37:14PM +0530, Srinidhi Kasagar wrote:
> On Thu, May 02, 2013 at 17:48:10 +0200, Lee Jones wrote:
> > drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c:
> > In function ‘synaptics_rmi4_resume’:
> > drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c:1090:18:
> > warning: ignoring return value of ‘regulator_enable’, declared
> > with attribute warn_unused_result [-Wunused-result
> >
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: devel@...verdev.osuosl.org
> > Signed-off-by: Lee Jones <lee.jones@...aro.org>
> > ---
> > drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> > index fe667dd..c4d013d 100644
> > --- a/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> > +++ b/drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
> > @@ -1087,7 +1087,9 @@ static int synaptics_rmi4_resume(struct device *dev)
> > unsigned char intr_status;
> > struct synaptics_rmi4_data *rmi4_data = dev_get_drvdata(dev);
> >
> > - regulator_enable(rmi4_data->regulator);
> > + retval = regulator_enable(rmi4_data->regulator);
> > + if (retval < 0)
> > + return retval;
> Does it make sense to add a dev_err?
>
Is that a question?
regulator_enable() already prints some warnings. Probably it's not
going to fail and adding code that is duplicative or will never be
run is pointless.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists