On Thu, 2024-06-27 at 09:38 +0530, Aditya Kumar Singh wrote: > > Couldn't we just have a flag in the channel context or so - there must > > be one, after all? And perhaps pass the chanctx from the driver instead > > of the channel? > > Not really. So this linked list thing came into picture for drivers > supporting split-band 5 GHz wiphy and both of them are grouped together > for MLO. Now, each one of them will use different chanctx as such and > there is a possibility of radar being detected simultaneously. Right so ... I don't see how that answers my question in the negative? You necessarily have a channel context for each channel you're listening (even for radar) on [unless you have the extra radar chain API thing], so if radar is detected, can't you just set a flag in that chanctx and kick off the processing? > Could do but, logic in worker will be little bit complex? > > for each ctx in local: > if ctx radar_detected flag is set: > append to local ctx list/array > num_ctx++ > > if num_ctx > 1 : > if wiphy supports mlo: > for each local ctx list/array: > call cfg80211_radar_event with the ctx chandef > else: > warn that mulit channel is not supported > else: > call cfg80211_radar_event with the first element in local ctx > list/array chandef > > ----- > > This is because, in split-band devices, ieee80211_radar_detected can be > called simultaneously with different channel contexts and then there is > a possibility that before worker gets a chance to execute, both of the > calls have marked their chanctx radar detected flags. Yeah, but no need to make that complex - simply doing for each ctx in local: if ctx radar_detected flag is set: call cfg80211_radar_event() with ctx chandef clear ctx radar_detected flag no? You don't have to restrict the worker to processing a single one, in fact you must not since scheduling it again while scheduled (and not yet running) won't run it again. And if it races then worst case you have a worker run that does nothing? johannes
