On 21 March 2014 16:07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2014-03-21 at 15:58 +0100, Michal Kazior wrote: > >> > Didn't we have this discussion on the hwsim patch before? >> >> Oh. I'm not aware of the discussion. Probably missed it. > > Or I got it wrong :) > >> > I'd argue that if all drivers must track this, then the mac80211 API is >> > defective. >> >> I can make this a mac80211 patch then? > > Yeah I guess. What was the reason for this though? Here it's multi-vif? > Before I think we were talking about races? Before multi-vif if ieee80211_csa_finalize() failed and left csa_active==true driver could end up poking the csa_finalize_work() over and over again I guess? For multi-vif csa using reservation there are 2 reasons: a) channel switches across interfaces may not be tightly synchronized. I did tests where 2 long (cs_count=100) channel switches were a few seconds apart. In that case driver poked csa_finalize work quite a lot resulting in a mess. b) my current approach has the following flow: 1. reserve_chanctx() 2. (some time later) driver calls csa_finish, and csa_finalize calls use_reserved_chanctx() because reserved_chanctx is set 3. (possibly some time later, for multi-vif reservations) csa_finalize is called again but this time without reserved_chanctx, so it verifies if bss_conf.chandef is csa_chandef (after successful reservation it should be). This means if driver would poke csa_finalize() more than once then use_reserved_chanctx() would be called again and again as a result. Michał -- 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
