Re: [RFC 3/9] nl80211/cfg80211: add ability to enable TX on op-channel

[Zefir Kurtisi <zefir.kurtisi@neratec.com>]

On 02/06/2012 02:01 PM, Goldenshtein, Victor wrote:
> On Mon, Feb 6, 2012 at 1:16 PM, zefir.kurtisi@gmail.com 
> <zefir.kurtisi@gmail.com> 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