[PATCH] libertas: before sleeping, check for a command result

[Dan Williams]

On Fri, 2008-05-23 at 16:26 +0200, Johan Adolfsson wrote:
> > -----Original Message-----
> > From: libertas-dev-bounces at lists.infradead.org 
> > [mailto:libertas-dev-bounces at lists.infradead.org] On Behalf 
> > Of Holger Schurig
> > Sent: den 23 maj 2008 16:04
> > To: libertas-dev at lists.infradead.org; Dan Williams; 
> > linux-wireless at vger.kernel.org; John W. Linville
> > Subject: [PATCH] libertas: before sleeping, check for a command result
> > 
> > 
> > If we don't check for a command response early, but rather sleep,
> > then we might sleep despite an already-received command response.
> > This will lead to a command-timeout.
> > 
> > Signed-off-by: Holger Schurig <hs4233 at mail.mn-solutions.de>
> > 
> > Index: wireless-testing/drivers/net/wireless/libertas/main.c
> > ===================================================================
> > --- 
> > wireless-testing.orig/drivers/net/wireless/libertas/main.c	
> > 2008-05-23 14:25:16.000000000 +0200
> > +++ wireless-testing/drivers/net/wireless/libertas/main.c	
> > 2008-05-23 14:25:51.000000000 +0200
> > @@ -722,14 +722,14 @@ static int lbs_thread(void *data)
> >  			shouldsleep = 1;	/* Something is 
> > en route to the device already */
> >  		else if (priv->tx_pending_len > 0)
> >  			shouldsleep = 0;	/* We've a 
> > packet to send */
> > +		else if (priv->resp_len[priv->resp_idx])
> > +			shouldsleep = 0;	/* We have a 
> > command response */
> >  		else if (priv->cur_cmd)
> >  			shouldsleep = 1;	/* Can't send a 
> > command; one already running */
> >  		else if (!list_empty(&priv->cmdpendingq))
> >  			shouldsleep = 0;	/* We have a 
> > command to send */
> >  		else if (__kfifo_len(priv->event_fifo))
> >  			shouldsleep = 0;	/* We have an 
> > event to process */
> 
> 
> Hi,
> I have experience a couple of timeout and resends and after 
> sending another commands I get the response from the previous one, 
> and the patch seems to solve a couple of those for me - 
> still se some problem fetching packet from  firmware with ret = -22 though.
> And it could be dependant on how much debug I have turned on..
> 
> But, shouldn't the above priv->event_fifo check move before
> cur_cmd  as well?

Most likely, yes...

> I have no clue what kind of events we are talking about here and
> if those can be processed independent of if a cmd is running or not,
> just trigged on the comment.

Anything that might be handled in lbs_process_event().  Link loss, MIC
failure, etc.

Dan

> Best regards
> /Johan
> 
>