From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lior Dotan <liodot@gmail.com>,
Christopher Harrer <charrer@alacritech.com>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: slicoss: remove unused variables
Date: Thu, 10 Sep 2015 18:52:22 +0530 [thread overview]
Message-ID: <20150910132222.GA20312@sudip-pc> (raw)
In-Reply-To: <20150909183137.GA7680@kroah.com>
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@vectorindia.org>
> > ---
> > 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. :)
regards
sudip
next prev parent reply other threads:[~2015-09-10 13:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 13:23 [PATCH] staging: slicoss: remove unused variables Sudip Mukherjee
2015-09-04 18:13 ` David Matlack
2015-09-05 8:08 ` Sudip Mukherjee
2015-09-09 18:31 ` Greg Kroah-Hartman
2015-09-10 13:22 ` Sudip Mukherjee [this message]
2015-09-12 2:51 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150910132222.GA20312@sudip-pc \
--to=sudipm.mukherjee@gmail.com \
--cc=charrer@alacritech.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liodot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox