Return-path: Received: from he.sipsolutions.net ([78.46.109.217]:42155 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757033Ab2F0PZi (ORCPT ); Wed, 27 Jun 2012 11:25:38 -0400 Message-ID: <1340810735.11012.44.camel@jlt3.sipsolutions.net> (sfid-20120627_172717_899467_DB02BF0A) Subject: Re: mac80211 auth/assoc in multi-channel scenarios From: Johannes Berg To: Arik Nemtsov Cc: Eliad Peller , linux-wireless Date: Wed, 27 Jun 2012 17:25:35 +0200 In-Reply-To: (sfid-20120627_172101_975306_3DA213AA) References: <1340640308.27437.16.camel@jlt3.sipsolutions.net> <1340707305.14634.9.camel@jlt3.sipsolutions.net> <1340795869.11012.12.camel@jlt3.sipsolutions.net> <1340807890.11012.43.camel@jlt3.sipsolutions.net> (sfid-20120627_172101_975306_3DA213AA) Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, 2012-06-27 at 18:20 +0300, Arik Nemtsov wrote: > > 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. Yeah, that was one of the other options I considered in my original email ... but this call must be able to sleep, and the TX processing in mac80211 cannot sleep, so unless we bypass all processing (which seems wrong) that would be rather difficult to implement. johannes