mbox series

[0/2] wifi: mac80211: Radar bitmap support during radar detection

Message ID 20221216070918.5969-1-quic_nmaran@quicinc.com (mailing list archive)
Headers show
Series wifi: mac80211: Radar bitmap support during radar detection | expand

Message

Nagarajan Maran Dec. 16, 2022, 7:09 a.m. UTC 
With the current implementation when radar is detected, the whole
configured DFS channels are moved to "unavailable" state(NOL).
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.
The "cf2_radar_bitmap" value will be valid only when the
"center_freq2" is available.

The LSB of the radar bitmap corresponds to the lowest 20 MHz channel
of the configured channel bandwidth. Each bit set to "1" in this radar
bitmap indicates that radar is detected in that sub-channel. Based
on this radar bitmap the radar affected channels alone will be moved
to NOL. Advertise these radar bitmaps using new NL attributes
"NL80211_ATTR_CF1_RADAR_BITMAP" and "NL80211_ATTR_CF2_RADAR_BITMAP"
with the existing "NL80211_CMD_RADAR_DETECT". Once these are
advertised and the needed dfs state propagation is done, reset these
radar bitmap values as they are not valid until there is another
radar detection.

With these radar bitmaps, we can support bandwidth reduction and
RX puncturing in the DFS Channels.

Nagarajan Maran (2):
  wifi: cfg80211: DFS radar detection support with radar bitmap
  wifi: mac80211: radar bitmap support during radar detection.

 drivers/net/wireless/ath/ath10k/debug.c       |  2 +-
 drivers/net/wireless/ath/ath10k/mac.c         |  2 +-
 drivers/net/wireless/ath/ath10k/wmi.c         |  2 +-
 drivers/net/wireless/ath/ath11k/wmi.c         |  2 +-
 drivers/net/wireless/ath/ath12k/wmi.c         |  2 +-
 drivers/net/wireless/ath/ath9k/dfs.c          |  2 +-
 drivers/net/wireless/ath/ath9k/dfs_debug.c    |  2 +-
 drivers/net/wireless/mac80211_hwsim.c         |  2 +-
 .../net/wireless/mediatek/mt76/mt7615/mcu.c   |  2 +-
 .../net/wireless/mediatek/mt76/mt76x02_dfs.c  |  4 ++--
 .../net/wireless/mediatek/mt76/mt7915/mcu.c   |  2 +-
 .../net/wireless/mediatek/mt76/mt7996/mcu.c   |  2 +-
 drivers/net/wireless/ti/wl18xx/event.c        |  2 +-
 include/net/cfg80211.h                        |  6 +++++
 include/net/mac80211.h                        |  5 +++-
 include/uapi/linux/nl80211.h                  | 11 +++++++++
 net/mac80211/ieee80211_i.h                    |  2 ++
 net/mac80211/util.c                           | 10 +++++++-
 net/wireless/chan.c                           | 24 ++++++++++++-------
 net/wireless/mlme.c                           |  4 ++++
 net/wireless/nl80211.c                        | 11 +++++++++
 net/wireless/reg.c                            |  3 +++
 22 files changed, 80 insertions(+), 24 deletions(-)


base-commit: 58e4b9df840cad439a4c878f81bc105cac2197a7

Comments

Johannes Berg Jan. 19, 2023, 2:08 p.m. UTC | #1 
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