On 14/11/2012 14:38, Johannes Berg wrote:
On Wed, 2012-11-14 at 13:32 +0100, Michal Kazior wrote:
Hmm. Maybe then the channel should be passed to the radar detection
command instead? That way, it can be passed through, you can allocate a
channel context, etc. Much easier?
I was thinking if putting the radar detection parameter in start_ap() is
an option (and thus removing the explicit radar cmd)? We could defer
`netif_carrier_on()` to be done after the initial radar detection is done.
Yeah, I was actually thinking that too for a bit, not sure if it works
though.
It won't, well.. at least not with current design. Userspace has the
responsibility to set the initial channel and reselect the next one if
necessary (if radar was detected), also it's responsible for the channel
availability check and its timing.
Moving radar detection to start AP will require additional DFS state
synchronization between kernel and userspace this why we initially
agreed to leave the DFS logic (CAC, channel selection etc..) in
userspace. Anyway, not sure what would we gain here.
--
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
