From mboxrd@z Thu Jan 1 00:00:00 1970 From: Quentin Deslandes Date: Thu, 16 May 2019 09:50:38 +0000 Subject: Re: [PATCH] staging: vt6656: remove unused variable Message-Id: <20190516095035.GA1692@qd-ubuntu> List-Id: References: <20190516093046.1400-1-quentin.deslandes@itdev.co.uk> <20190516093951.GA19798@kroah.com> In-Reply-To: <20190516093951.GA19798@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Greg Kroah-Hartman Cc: "kernel-janitors@vger.kernel.org" , "devel@driverdev.osuosl.org" , Forest Bond , "linux-kernel@vger.kernel.org" On Thu, May 16, 2019 at 11:39:51AM +0200, Greg Kroah-Hartman wrote: > On Thu, May 16, 2019 at 09:31:05AM +0000, Quentin Deslandes wrote: > > Fixed 'set but not used' warning message on a status variable. The > > called function returning the status code 'vnt_start_interrupt_urb()' > > clean up after itself and the caller function > > 'vnt_int_start_interrupt()' does not returns any value. > > > > Signed-off-by: Quentin Deslandes > > --- > > drivers/staging/vt6656/int.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/staging/vt6656/int.c b/drivers/staging/vt6656/int.c > > index 504424b19fcf..ac30ce72db5a 100644 > > --- a/drivers/staging/vt6656/int.c > > +++ b/drivers/staging/vt6656/int.c > > @@ -42,13 +42,12 @@ static const u8 fallback_rate1[5][5] = { > > void vnt_int_start_interrupt(struct vnt_private *priv) > > { > > unsigned long flags; > > - int status; > > > > dev_dbg(&priv->usb->dev, "---->Interrupt Polling Thread\n"); > > > > spin_lock_irqsave(&priv->lock, flags); > > > > - status = vnt_start_interrupt_urb(priv); > > + vnt_start_interrupt_urb(priv); > > Shouldn't you fix this by erroring out if this fails? Why ignore the > errors? > > thanks, > > greg k-h I could, however 'vnt_start_interrupt_urb()' already call 'dev_dbg()' if it fails. Nothing is done after this debug call except returning an error code. 'vnt_int_start_interrupt()' should, IMHO, return a status code, but the original developer may have good reasons not to do so. Thank you, Quentin