On Wed, Jun 27, 2012 at 5:38 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2012-06-27 at 14:27 +0300, Arik Nemtsov wrote: >> On Wed, Jun 27, 2012 at 2:17 PM, Johannes Berg >> <johannes@xxxxxxxxxxxxxxxx> wrote: >> > On Tue, 2012-06-26 at 14:35 +0300, Arik Nemtsov wrote: >> > >> >> Can you give a bit more info on the Tx-sync approach, for the uninitiated? >> >> I'm also thinking that maybe we could somehow treat the sleeping-GO as >> >> a special case (maybe with some special code and a HW flag). Right now >> >> I'm not sure the wl12xx FW even supports it. >> > >> > I basically had a simpler version in mind, something like this: >> > http://p.sipsolutions.net/cd928e926a941ac7.txt >> >> If the low level driver has to prepare for each such Tx, that's fine. > > If it doesn't, then it can de-duplicate itself I guess? And it can also > abort everything (if needed) when the bssid is cleared (failure) or when > we go into associated (success), so I didn't add an explicit cancel > operation. Ok. > >> But does this somehow rely on the timing of the Tx? Relying on op_tx >> to come right after this seems racy. > > It'll depend on the driver I guess? If you're going to set a flag "give > this vif priority now" on the first invocation, then you probably > wouldn't care about the timing. It looks like our implementation would > actually start some "give me the channel" operation and when the > firmware says "ok you have the channel now" we'd return and rely on > getting the TX right after. > > Wrt. the race, this isn't going to be something that happens within less > than a millisecond or so, it's going to give us maybe 50ms at least of > channel time (WFA mandates replying within 30ms), so that doesn't seem > like a problem? It's probably not an issue. Just seems simpler to just give the skb to the driver so it can do whatever it wants before/during/after. Bypass op_tx completely for these. -- 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
