On Wed, 2014-05-07 at 09:25 +0200, Michal Kazior wrote: > > Should csa_active really stay true in the reserved_chanctx case? > > Wouldn't that leave it beaconing, with potentially suddenly negative > > (due to underflow) CSA counter, or something? > > Hmm.. I think drivers should check ieee80211_csa_is_complete() before > calling to ieee80211_beacon_get(). At least that's what ath9k and > ath10k effectively do now. Hwsim might complain though but this should > be changed for multi-vif CSA. You may need to wait for other vifs to > finish CS (the incompat case) so you shouldn't call > ieee80211_beacon_get() after you get last CSA beacon on a given AP > vif. I don't think that works for all drivers - only drivers that actually generate and tx each beacon - but other drivers just update a template. We actually have some pending patches to make that work correctly for the CSA counters, but I'm not really sure what you want to happen in the case that one is switching while the other hasn't yet? Should it stop beaconing? Seems like clients would give up the switch then, no? > Btw. shouldn't csa_active be protected/synchronized between CPUs > somehow? I think it's possible now to get inconsistencies and hit > WARN_ONs due to that. I suppose it should then, I didn't write it :) 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
