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. > 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? johannes -- 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
