> 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.. Keep in mind that maybe the firmware actually really takes ages to complete a command. David Woodhouse reported this. In my case, because I had the proper debugging statements in my interrupt handler, I knew for sure that I already received the response. Can you verify that, for the comment timeouts you noticed, if this did happen or not? > But, shouldn't the above priv->event_fifo check move before > cur_cmd as well? Maybe, my change to the thread was just a shot into the dark, I don't claim that I fully understand it. Maybe Dan or David can help you with this. > 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. The kfifo contains hostevents (e.g. link lost, deauthenticated) and command responses. Hmm, not sure if the latter is still true. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html