On Wed, 2014-05-07 at 09:25 +0200, Michal Kazior wrote:

quoted

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