From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754579AbbILEf3 (ORCPT ); Sat, 12 Sep 2015 00:35:29 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:57837 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754537AbbILEf0 (ORCPT ); Sat, 12 Sep 2015 00:35:26 -0400 Date: Fri, 11 Sep 2015 19:51:38 -0700 From: Greg Kroah-Hartman To: Sudip Mukherjee Cc: devel@driverdev.osuosl.org, Christopher Harrer , Lior Dotan , linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging: slicoss: remove unused variables Message-ID: <20150912025138.GA25966@kroah.com> References: <1441372998-22760-1-git-send-email-sudipm.mukherjee@gmail.com> <20150909183137.GA7680@kroah.com> <20150910132222.GA20312@sudip-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150910132222.GA20312@sudip-pc> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 10, 2015 at 06:52:22PM +0530, Sudip Mukherjee wrote: > On Wed, Sep 09, 2015 at 11:31:37AM -0700, Greg Kroah-Hartman wrote: > > On Fri, Sep 04, 2015 at 06:53:18PM +0530, Sudip Mukherjee wrote: > > > These variables were only assigned some values but they were never used. > > > > > > Signed-off-by: Sudip Mukherjee > > > --- > > > drivers/staging/slicoss/slicoss.c | 27 ++++++--------------------- > > > 1 file changed, 6 insertions(+), 21 deletions(-) > > > > > > diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c > > > index 8585970..1536ca0 100644 > > > --- a/drivers/staging/slicoss/slicoss.c > > > +++ b/drivers/staging/slicoss/slicoss.c > > > > @@ -1730,15 +1727,13 @@ static void slic_link_event_handler(struct adapter *adapter) > > > pshmem = (struct slic_shmem *)(unsigned long)adapter->phys_shmem; > > > > > > #if BITS_PER_LONG == 64 > > > - status = slic_upr_request(adapter, > > > - SLIC_UPR_RLSR, > > > - SLIC_GET_ADDR_LOW(&pshmem->linkstatus), > > > - SLIC_GET_ADDR_HIGH(&pshmem->linkstatus), > > > - 0, 0); > > > + slic_upr_request(adapter, SLIC_UPR_RLSR, > > > + SLIC_GET_ADDR_LOW(&pshmem->linkstatus), > > > + SLIC_GET_ADDR_HIGH(&pshmem->linkstatus), 0, 0); > > > #else > > > - status = slic_upr_request(adapter, SLIC_UPR_RLSR, > > > - (u32) &pshmem->linkstatus, /* no 4GB wrap guaranteed */ > > > - 0, 0, 0); > > > + slic_upr_request(adapter, SLIC_UPR_RLSR, > > > + (u32)&pshmem->linkstatus, /* no 4GB wrap guaranteed */ > > > + 0, 0, 0); > > > > Shouldn't we do something with status instead of just ignoring it? > I can think of 3 possibilities. > 1) Ignore it as this is writing READ_LINK_STATUS command to the device > asynchronously, and then writing UP configuration command. So if status > is error here then the device will not be UP. > > 2) loop here with a delay until the call succeeds. (will be a very bad > design, but there are some codes doing that). But this functions is also > called from an ISR so we should not be doing that. > > 3) return the error code and do the error handling properly by clearing > and releasing all resources acquired by the function which called it. > > Which one will you suggest? I am sure you will say : 3. :) I don't know why you even had to ask, of course 3 is the correct thing :)