On Fri, 2022-12-16 at 12:39 +0530, Nagarajan Maran wrote: > With the current implementation when radar is detected, the whole > configured DFS channels are moved to "unavailable" state(NOL). OK, sure. > However to move only the radar affected channels alone to NOL, > introducing two unsigned 16bit variables "cf1_radar_bitmap" and > "cf2_radar_bitmap" which denotes the radar(with a granularity of > 20 MHz) in the first and the second part of the channel respectively. Where do they come from? It's not really clear to me, you just have them in the chandef... passing them indirectly like that seems like a really problematic idea to me? I really don't think they should be in a chandef. They have no meaning on configuration ... similar (but worse in a way) to the discussion we had for puncturing. Also, as far as cfg80211 is concerned, this information originally comes in via __cfg80211_radar_event(). Why not just call __cfg80211_radar_event() for each sub-channel separately (yes that might need some better handling of the work structs etc. there, possibly with a queue of events rather than just "memcpy(&rdev->radar_chandef, ...)")? I can't say I like the way you've handled this here. If we really need to have a single "radar event" rather than multiple (but then explain why) then these could be extra arguments to __cfg80211_radar_event() I guess, but right now I'm not sure I see any reason for that vs. just calling __cfg80211_radar_event() multiple times for each affected 20 MHz channel? johannes
