Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1221675 > unrolled thread
| Started by | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| First post | 2015-09-09 22:00 +0200 |
| Last post | 2015-09-12 06:40 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] staging: slicoss: remove unused variables Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-09 22:00 +0200
Re: [PATCH] staging: slicoss: remove unused variables Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-10 15:30 +0200
Re: [PATCH] staging: slicoss: remove unused variables Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2015-09-12 06:40 +0200
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2015-09-09 22:00 +0200 |
| Subject | Re: [PATCH] staging: slicoss: remove unused variables |
| Message-ID | <q6THd-4vo-31@gated-at.bofh.it> |
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
> @@ -199,10 +199,8 @@ static void slic_mcast_set_mask(struct adapter *adapter)
> static void slic_timer_ping(ulong dev)
> {
> struct adapter *adapter;
> - struct sliccard *card;
>
> adapter = netdev_priv((struct net_device *)dev);
> - card = adapter->card;
>
> adapter->pingtimer.expires = jiffies + (PING_TIMER_INTERVAL * HZ);
> add_timer(&adapter->pingtimer);
> @@ -1719,7 +1717,6 @@ static u32 slic_rcvqueue_reinsert(struct adapter *adapter, struct sk_buff *skb)
> */
> static void slic_link_event_handler(struct adapter *adapter)
> {
> - int status;
> struct slic_shmem *pshmem;
>
> if (adapter->state != ADAPT_UP) {
> @@ -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?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Sudip Mukherjee <sudipm.mukherjee@gmail.com> |
|---|---|
| Date | 2015-09-10 15:30 +0200 |
| Message-ID | <q7a5l-2Ey-29@gated-at.bofh.it> |
| In reply to | #1221675 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2015-09-12 06:40 +0200 |
| Message-ID | <q7KLv-6L3-11@gated-at.bofh.it> |
| In reply to | #1222195 |
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@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. :) I don't know why you even had to ask, of course 3 is the correct thing :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web