Search Linux Wireless

Re: [PATCH v2 8/9] wifi: mac80211: handle ieee80211_radar_detected() for MLO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/28/24 14:29, Johannes Berg wrote:
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?


Ah! okay. Now I see your point. Sorry partially misunderstood earlier. Yeah this can be done.

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?


Yes got it. Thanks for clearing it out.

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?


Yes, true that. Sure so let me incorporate these changes and send next version soon. Thanks for the suggestions.

- Aditya





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux