From: Kalle Valo <kalle.valo@iki.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: wey-yi.w.guy@intel.com, linux-wireless@vger.kernel.org, j@w1.fi
Subject: Re: [PATCH v3 1/1] mac80211: tell driver when dtim change detected
Date: Sat, 23 Jan 2010 10:23:22 +0200 [thread overview]
Message-ID: <87y6jpp6v9.fsf@purkki.valot.fi> (raw)
In-Reply-To: <1264186981.2593.10.camel@johannes.local> (Johannes Berg's message of "Fri\, 22 Jan 2010 20\:03\:01 +0100")
Johannes Berg <johannes@sipsolutions.net> writes:
> However, I think it's indicative of a bigger problem. I gave it some
> thought, and came to the conclusion that it previously didn't happen
> because we always won the race. Let me explain.
One more reason why need to receive the beacon is synchronisation to
the beacon for power save. For example wl1251 and wl1271 want to
receive one beacon for synchronisation purposes before some of the
commands are executed. It would be really nice if mac80211 would take
care of that.
> First, we could go back to the original behaviour if we have just one
> virtual interface.
I think this is good to have. Just to keep it simple for devices like
wl1251 and wl1271.
> But that still leaves us with the race, we might do all three frame
> exchanges within a beacon interval and still miss the beacon, we
> just tend to not do that and get a beacon.
>
> The other solution I see is that we add a new step before or after the
> direct probe step, which would just be "wait for a beacon". This would
> ensure we have both probe and beacon information always ready. It would
> also ensure we have both probe and beacon info for our new userspace
> reporting of that.
I like this. If only the bssid would be provided to the driver before
the association process, both wl1251 and wl1271 would not have to
worry about firmware beacon synchronisation.
--
Kalle Valo
next prev parent reply other threads:[~2010-01-23 8:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 21:39 [PATCH v3 1/1] mac80211: tell driver when dtim change detected wey-yi.w.guy
2010-01-22 19:03 ` Johannes Berg
2010-01-22 19:20 ` Luis R. Rodriguez
2010-01-22 19:46 ` Johannes Berg
2010-01-22 23:44 ` Luis R. Rodriguez
2010-01-22 23:45 ` Luis R. Rodriguez
2010-01-23 0:11 ` Guy, Wey-Yi
2010-01-23 0:23 ` Luis R. Rodriguez
2010-01-23 0:22 ` Guy, Wey-Yi
2010-01-23 12:46 ` Johannes Berg
2010-01-25 18:18 ` Luis R. Rodriguez
2010-01-25 18:33 ` Johannes Berg
2010-01-25 19:55 ` Luis R. Rodriguez
2010-01-25 20:06 ` Johannes Berg
2010-01-26 8:41 ` Kalle Valo
2010-01-25 18:32 ` Jouni Malinen
2010-01-25 18:36 ` Johannes Berg
2010-01-25 18:38 ` Johannes Berg
2010-01-23 8:23 ` Kalle Valo [this message]
2010-01-25 18:35 ` Jouni Malinen
2010-01-25 20:11 ` Johannes Berg
2010-01-25 20:46 ` Guy, Wey-Yi
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=87y6jpp6v9.fsf@purkki.valot.fi \
--to=kalle.valo@iki.fi \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=wey-yi.w.guy@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox