Re: [PATCH 09/10] carl9170: fw: enable DFS radar detection

[John Scott <jscott@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 4857 bytes --]

Hello,
I have a question about how this fits into the wireless regulatory status quo, as someone who doesn't understand the code too well but is interested.
Currently it appears ath9k guards radar detection behind a Kconfig option, and the details look important:
> config ATH9K_DFS_CERTIFIED
> 	bool "Atheros DFS support for certified platforms"
> 	depends on ATH9K && CFG80211_CERTIFICATION_ONUS
> 	default n
> 	help
> 	  This option enables DFS support for initiating radiation on
> 	  ath9k. There is no way to dynamically detect if a card was DFS
> 	  certified and as such this is left as a build time option. This
> 	  option should only be enabled by system integrators that can
> 	  guarantee that all the platforms that their kernel will run on
> 	  have obtained appropriate regulatory body certification for a
> 	  respective Atheros card by using ath9k on the target shipping
> 	  platforms.
> 
> 	  This is currently only a placeholder for future DFS support,
> 	  as DFS support requires more components that still need to be
> 	  developed. At this point enabling this option won't do anything
> 	  except increase code size.
(I think that last paragraph is out of date—my understanding is ath9k has supported DFS for a while, at least when used in tandem with wpa_supplicant, but I've not had the pleasure to try that yet.)
I see this option depends on CFG80211_CERTIFICATION_ONUS, which, indeed, is an affirmation from the kernel configurator that this will be used in such a conforming environment. Does carl9170 need to do something similar before turning this on? From the several AR9170 NICs I have in my collection, none of them have FCC approval for radar detection as far as I know. (Does anyone know of any?)
Perhaps the sentiment of Linux Wireless folks is different now—I think ath9k was the original prototype for radar detection, anyway—but could this be a problem?

On Thu, 2026-03-12, Masi Osmani wrote:
> Enable DFS (Dynamic Frequency Selection) radar detection on the
> AR9170.  The hardware has radar detection registers (RADAR_0,
> RADAR_1, RADAR_EXT) and the firmware already sends
> CARL9170_RSP_RADAR events, but the driver never programmed the
> detection parameters and only logged a "please report" message.
> 
> Changes:
> - Program radar detection pulse parameters in phy.c when the
>   current channel has IEEE80211_CHAN_RADAR set.  Values are
>   based on ath9k defaults for FCC/ETSI compliance.
I see cfg80211.h says
> @IEEE80211_CHAN_RADAR: Radar detection is required on this channel.
so this *appears* to affirm my mild concern that this patch is intended to permit initiating radiation on such channels. Is that right?

> - Advertise radar_detect_widths in the interface combination
>   (fw.c) for 20 MHz noHT, 20 MHz HT, and 40 MHz HT.
> - Replace the old "please report" message with a call to
>   ieee80211_radar_detected() so mac80211 can trigger the
>   proper DFS state machine (channel switch / CAC).
> 
> Signed-off-by: Masi Osmani <mas-i@hotmail.de>
> ---
>  drivers/net/wireless/ath/carl9170/fw.c  |  3 ++
>  drivers/net/wireless/ath/carl9170/phy.c | 45 +++++++++++++++++++++++++
>  drivers/net/wireless/ath/carl9170/rx.c  |  7 ++--
>  3 files changed, 50 insertions(+), 5 deletions(-)
Thus it appears no Kconfig changes were made and your changes don't guard radar detection behind a suitable preprocessor directive.

By the way, I notice in include/net/mac80211.h
/**
 * struct ieee80211_conf - configuration of the device
 *
 * This struct indicates how the driver shall configure the hardware.
 * ...
 * [bool] @radar_enabled: whether radar detection is enabled
 */
Is this .radar_enabled member something that should be checked or used as part of these changes? I don't know anymore about this code than the plain meaning of the words, but I thought I'd ask: a patch to enable radar detection seems like it ought to access such an object named "radar_enabled" at some point, right?

P.S. Although I don't have access to formal industrial testing equipment, I'm in Central Indiana, USA and I already have a couple creative ideas to put radar detection to the test, at least to assess effectiveness of the implementation. Perhaps comrades from my local Linux Users Group could join me (field trip!), if I do some more research to ascertain the frequency bands used. "It doesn't hurt to ask" 🙂
There are legitimate circumstances where DFS/radar detection can be enabled even if the FCC Part 15 certification wasn't performed for the hardware—such as when operating under rules other than conventional FCC Part 15 (some amateur radio licensees, limited non-commercial usage and experimentation). So even putting this behind something like a "CARL9170_DFS_CERTIFIED" would still be neat if we could show its usefulness

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 411 bytes --]