On 02/06/2012 02:01 PM, Goldenshtein, Victor wrote: > 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? > So the driver does not need to be aware of disabled TX condition at all, since hostapd ensures that no TX will happen during CAC? What is then your FLAG_DFS_CAC_IN_PROGRESS used for? As for the naming, I'd maybe call them just dfs_start_cac() and dfs_end_cac(), but am also fine with the 'resume' variant. > >> 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. > > Yeah, having a working reference implementation would definitively help. Thanks, 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
