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 <sudip@xxxxxxxxxxxxxxx> > > > --- > > > 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 > <snip> > > > @@ -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 :) _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
