On 04/05/2013 01:29 PM, Simon Wunderlich wrote: > Hello Zefir, > > > Thanks for explaining, I could now see what's happening. I've added another > debug messages for "DFS not enabled" in the other case. What I get when running > your example (and with my patch applied) is: > > NOTE: hostapd started > [ 668.576380] ath: phy0: DFS not enabled at freq 5540 > [ 668.594108] ath: phy0: DFS enabled at freq 5540 > [ 672.607996] ath: phy0: DFS enabled at freq 5540 > [ 672.928911] ath: phy0: DFS enabled at freq 5540 > [ 672.939416] ath: phy0: DFS enabled at freq 5540 > [ 704.128876] ath: phy0: DFS enabled at freq 5540 > NOTE: radar triggered here > [ 704.138482] ath: phy0: DFS enabled at freq 5240 > [ 704.149684] ath: phy0: DFS not enabled at freq 5240 > > Now what happens is: > 1. vif_use_channel() calls ieee80211_new_chanctx(), which calls ieee80211_hw_config(). > radar flags are not "recalc"d, so the previous value is used > 2. Later in vif_use_channel(), ieee80211_recalc_radar_chanctx() is called, which > sets the radar flag and calls ieee80211_hw_config() again. > > As you can see in the output, the right value is applied ~10 - 20ms after the wrong > value, at least with the patch originally posted here. > > Of course this is not beautiful, but should work in practice. > > We could consider changing this by already applying the correct radar flag in > ieee80211_new_chanctx()? If you want, I can post a patch for that. SMPS probably > has a similar problem to have the wrong value you set for a short time ... > > Thanks for double-checking, Simon. I failed to see the obvious (that ath_config() is called immediately again with the correct DFS flag), sorry for raising dust. Whether fix it or not, I'd say it is good enough for ath9k. Might be different for other chips that don't allow enabling radar detection on non-DFS channels (even if it is only for some ms). Cheers, Zefir -- 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
