All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Bing Zhao <bzhao@marvell.com>
Cc: linux-wireless@vger.kernel.org,
	"John W. Linville" <linville@tuxdriver.com>,
	Amitkumar Karwar <akarwar@marvell.com>,
	Kiran Divekar <dkiran@marvell.com>,
	Yogesh Powar <yogeshp@marvell.com>,
	Frank Huang <frankh@marvell.com>
Subject: Re: [PATCH] mwifiex: use separate wait queue for each command node
Date: Tue, 04 Oct 2011 08:29:48 +0200	[thread overview]
Message-ID: <1317709788.3986.0.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1317701303-21871-1-git-send-email-bzhao@marvell.com> (sfid-20111004_061336_546510_9B44E171)

On Mon, 2011-10-03 at 21:08 -0700, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar@marvell.com>
> 
> Currently global wait queue (adapter->cmd_wait_q) is used for
> sending synchronous commands to FW. When two threads enter in
> mwifiex_send_cmd_sync() routine at the same time, both the
> threads wait for their command responses. They wake up
> simultaneously after getting response of 1st command. After
> this when a thread is waiting for command response of 3rd
> command, it wakes up after getting response of 2nd command
> and so on. Therefore we don't wait for the response of last
> command(0xaa) during unload. Hence while next time loading the
> driver command time out is seen for INIT command.
> 
> This problem is resolved by having separate wait queue for each
> command. Since driver sends multiple scan commands asynchronously
> to FW for scanning the network, we will need separate wait queue
> for the whole scan operation. Earlier the global wait queue was
> being used for scan.

I can't say I really care about this, but this seems completely
pointless. A waitqueue doesn't imply that just a single thing can be
waiting on it, since you should be using wait_for() macros. Thus, all
you *really* need is a bit in the command that marks it as completed,
and then you use the waitqueue to wait for that bit to be set.

johannes



  parent reply	other threads:[~2011-10-04  6:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-04  4:08 [PATCH] mwifiex: use separate wait queue for each command node Bing Zhao
2011-10-04  4:08 ` [PATCH] mwifiex: add support for Marvell pcie8766 chipset Bing Zhao
2011-10-07  3:30   ` Bing Zhao
2011-10-11 20:39     ` John W. Linville
2011-10-11 21:32       ` Bing Zhao
2011-10-04  6:29 ` Johannes Berg [this message]
2011-10-04 18:50   ` [PATCH] mwifiex: use separate wait queue for each command node Bing Zhao

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=1317709788.3986.0.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=akarwar@marvell.com \
    --cc=bzhao@marvell.com \
    --cc=dkiran@marvell.com \
    --cc=frankh@marvell.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=yogeshp@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.