On Tue, 2012-11-20 at 17:15 +0200, Victor Goldenshtein wrote: > 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. Fair enough. I think we can solve it differently, like I outlined in my first mail today. johannes -- 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
