Hey Karl,
> Sorry, I was not very clear.
> What I meant is that, my change for hwsim is not correct because it
> assumed something like what's above that would prevent beacon_get() to
> return a beacon when csa is under completion. Instead, it should check
> for csa completion prior to getting the beacon.
>
> Checking your ath9k change for CSA, I am under the impression this is
> possible ? : {{{
> ath9k_channel_switch_beacon()
> ath9k_beacon_tasklet()
> ath9k_csa_is_finished() // ret false
> ..
> ath9k_beacon_tasklet()
> ath9k_csa_is_finished() // sets sc->csa_vif to NULL, ret true
> ieee80211_csa_finish() // schedules csa work
>
> ath9k_beacon_tasklet()
> ath9k_csa_is_finished() // ret false because sc->csa_vif==NULL
>
> csa_finalize_work() // too late
> }}}
Yeah, you are right, if the worker is too late ath9k still generates a beacon
and will hit a warning that the csa was already finished. Actually that helped
quite a lot while developing the feature.
In practice, I don't think it's that bad - the worker shouldn't take so long
too respond, and also it does not hurt to generate/send the beacon one more
time on the same channel with count = 0 (or 1). It's useful to get a warning
in this case so that the root cause for the delay can be worked on.
What do you think? I can change that easily in ath9k otherwise. :)
Thanks,
Simon
--
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
