All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhu Yi <yi.zhu@intel.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] cfg80211: set SME state machine correctly for roam event
Date: Fri, 14 Aug 2009 11:58:21 +0800	[thread overview]
Message-ID: <1250222301.4972.31.camel@debian> (raw)
In-Reply-To: <1250157249.21250.0.camel@johannes.local>

On Thu, 2009-08-13 at 17:54 +0800, Johannes Berg wrote:
> On Thu, 2009-08-13 at 17:23 +0800, Zhu Yi wrote:
> > When we receive a successful status in CFG80211_SME_CONNECTED state,
> > it is a roam event. We should mark it as a success result.
> 
> But there's a cfg80211_roamed() call for that? Can the driver not tell
> the difference? It also sends a different event (ROAMED rather than
> CONNECTED) to userspace.

The device notifies both when it begins to roam and after the new
association is made. Yes, I think I missed the cfg80211_roamed call for
the real roam event. But there is still a reassociation path that the
above situation could happen (__cfg80211_connect_result is called while
in CFG80211_SME_CONNECTED state). Or do you think we should suppress
reassoc event from driver?

Actually, the code in __cfg80211_connect_result() has already handled
the (wdev->sme_state == CFG80211_SME_CONNECTED) case. The problem is
wdev->current_bss is set to NULL but leaves wdev->sme_state still as
CFG80211_SME_CONNECTED. So I think the patch is still valid, but needs a
better description.

Thanks,
-yi


  reply	other threads:[~2009-08-14  3:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-13  9:23 [PATCH] cfg80211: set SME state machine correctly for roam event Zhu Yi
2009-08-13  9:54 ` Johannes Berg
2009-08-14  3:58   ` Zhu Yi [this message]
2009-08-14 14:54     ` Johannes Berg
2009-08-17  2:35       ` Zhu Yi
2009-08-17  7:23         ` Johannes Berg
2009-08-14 16:05   ` Jussi Kivilinna

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=1250222301.4972.31.camel@debian \
    --to=yi.zhu@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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.