On Mon, Feb 6, 2012 at 1:16 PM, zefir.kurtisi@xxxxxxxxx <zefir.kurtisi@xxxxxxxxx> wrote: > I noticed this issue working on interfacing ath9k to your DFS management component. When a DFS channel is initially set, the driver has no information whether to block TX or not (as opposed to ap_process_chanswitch() providing these flags). What is the assumption here? Is the driver required to check itself whether a DFS channel is set and raise some internal tx_disabled flag to be reset via hw_dfs_en_tx()? With all the logic being located in hostap, this looks inconsistent (but doable). > When a DFS channel is initially set (with hostapd_set_freq()) the AP is during early init phase and obviously not transmitting anything yet at this point, the AP should start the tx (transmitting beacons) only after hostapd_setup_bss() call, which is blocked until we validate the channel for radar clearness. If during the CAC tes a radar is detected we select and set another frequency/channel (still with hostapd_set_freq()) and start the radar detection once again for the new freq. Once the channel pass the "channel availability check" we continue with the init flow as usual. IMHO the driver doesn't need to block anything at this point and no flag is required. In wl12xx we have one "FLAG_DFS_CAC_IN_PROGRESS" which basically indicates that we're in the middle of a CAC test and no tx can occur during this period. This flag is set during "hw_dfs_start_radar_detection()" and unset during hw_dfs_en_tx(), this is one of the reason that I thought to change the "hw_dfs_en_tx()" to something like "dfs_resume_cac()", in this case it would be also aligned with "hostapd_resume_dfs_cac()" callback, what do you think about this? > Aside from that, I managed to interface ath9k to the proposed component. So far, it enables me to set up a DFS monitor to physically test my pattern detectors, while it fails to run in master mode. Need to go through the trace logs to isolate the problem and will report then. > We're planning to release wl12xx DFS RFC which might help better understand the DFS implementation from driver's point of view. -- Thanks, Victor. -- 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
