On Fri, Apr 05, 2013 at 02:36:04PM +0200, Johannes Berg wrote: > On Fri, 2013-04-05 at 14:16 +0200, Simon Wunderlich wrote: > > On Fri, Apr 05, 2013 at 01:22:51PM +0200, Johannes Berg wrote: > > > On Thu, 2013-04-04 at 20:22 +0200, Simon Wunderlich wrote: > > > > > > > As far as I see, the problem happens when changing from a DFS to a non-DFS > > > > channel. local->hw.conf.radar_enabled is true from the last (DFS) channel, > > > > but the channel gets released when stopping the AP, and the channel context > > > > is freed. > > > > > > At this point, why doesn't it disable hw.conf.radar_enabled? I really > > > think it should? > > > > As far as I see release_channel() -> unassign_vif_chanctx() -> ieee80211_recalc_radar_chanctx() > > is called while the interface with radar enabled is still present, and therefore it is assumed > > that the radar enable is still required. > > > > We could reset local->hw.conf.radar_enabled ieee80211_free_chanctx() though, but IMHO the cleaner > > way would be to properly initialize it when the the channel is used next time through > > vif_use_channel(). > > I disagree, it would leave the hardware in a weird state -- idle but > having to detect radars?? > > johannes Well, you have a point ... I'll look into it, it should be doable that the radar flag is always set correctly. Please drop this patch for now. Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
