On 6/26/24 18:05, Johannes Berg wrote:
On Wed, 2024-06-26 at 10:22 +0530, Aditya Kumar Singh wrote:
Hence, in order to support DFS with MLO, do the following changes -
* Add channel pointer as an argument to the function
ieee80211_radar_detected(). During MLO, drivers would have to pass on
which channel radar is detected.
Makes sense, maybe?
* In order to pass on this channel information to the radar detected
worker later on, introduce a linked list 'radar_info' in the structure
local.
* When driver calls radar detected, a node is created and added to this
list and work is scheduled. The work handler takes care to process each
node and take further action.
Not sure I like that so much, it adds book-keeping and all kinds of
extra things.
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?
Actually, we're already having to do a channel/chanctx lookup in
ieee80211_dfs_radar_detected_work() so it seems pretty weird to add more
complex logic to it...
Please consider just passing the chanctx, and then we can set a flag
there, and not have any of this.
So I was trying to implement above suggestion, and I see this -
* Drivers don't have chanctx visible in it. Driver visible part is
ieee80211_chanctx_conf (stored in chanctx)
* In order to pass this from driver, I need to access each driver's per
interface struct which should have ieee80211_vif. This will have
bss_conf pointer and in turn which will have chanctx_conf pointer.
(per_vif_struct)->vif->bss_conf->chanctx_conf.
* I see for many drivers the place where ieee80211_radar_detected() is
called, the interface level struct is not present. So making
chanctx_conf mandatory argument to pass requires a lot of code changes
across the drivers.
* So in order to keep things simple, we'd have to allow drivers to pass
NULL and let the current logic kick in. Iterate over all ctxs and all those.
* If driver passes chanctx_conf, then while going through the ctx, if
the flag is set, further process can immediately kick in and other
num_ctx checks will be ignored.
* Now if driver has clubbed multiple hardwares under single wiphy due to
which num_ctx will be greater than 1, obviously such drivers are bound
to pass a valid chanctx_conf or else the event will be dropped.
Sounds fine?
