wireless-regdb: IN DFS ranges result in DFS_UNSET and prevent mt76 CAC

Hi,

I am seeing an immediate DFS/CAC failure on an OpenWrt 24.10.0 based
system using MT7915E/mt76 with country code IN.

Environment:

  Device: YunCore AX820
  SoC: MediaTek MT7621
  Wi-Fi: MediaTek MT7915E
  OpenWrt: 24.10.0 r28427-6df0e3d02a
  Kernel: 6.6.73
  mt76: 2025.01.14~8e4f72b6
  wireless-regdb: 2024.10.07

The India entry in db.txt is:

  country IN:
      (2402 - 2482 @ 40), (30)
      (5150 - 5250 @ 80), (30)
      (5250 - 5350 @ 80), (24), DFS
      (5470 - 5725 @ 160), (24), DFS
      (5725 - 5875 @ 80), (30)

The DFS frequency ranges are marked with DFS, but the country entry does
not specify DFS-FCC, DFS-ETSI, or DFS-JP.

On the device:

  iw reg get

reports:

  country IN: DFS-UNSET

When I configure channel 100, hostapd reports:

  phy1-ap0: interface state COUNTRY_UPDATE->DFS
  phy1-ap0: DFS-CAC-START freq=5500 chan=100 sec_chan=0,
             width=0, seg0=0, seg1=0, cac_time=60s
  DFS start_dfs_cac() failed, -1
  phy1-ap0: interface state DFS->DISABLED
  phy1-ap0: AP-DISABLED

The failure is immediate; CAC does not run for 60 seconds.

I added temporary instrumentation in mt76. During a transition from
working non-DFS channel 157 to DFS channel 100, I see:

  DFSDBG: region=0 dfs_state=1 prev_state=0

The relevant mt76 enum is:

  enum mt76_dfs_state {
      MT_DFS_STATE_UNKNOWN,
      MT_DFS_STATE_DISABLED,
      MT_DFS_STATE_CAC,
      MT_DFS_STATE_ACTIVE,
  };

Therefore the runtime values correspond to:

  prev_state = 0 = MT_DFS_STATE_UNKNOWN
  dfs_state  = 1 = MT_DFS_STATE_DISABLED

The relevant mt76 function is:

  enum mt76_dfs_state mt76_phy_dfs_state(struct mt76_phy *phy)
  {
      struct ieee80211_hw *hw = phy->hw;
      struct mt76_dev *dev = phy->dev;

      if (dev->region == NL80211_DFS_UNSET ||
          test_bit(MT76_SCANNING, &phy->state))
          return MT_DFS_STATE_DISABLED;

      if (!phy->radar_enabled) {
          if ((hw->conf.flags & IEEE80211_CONF_MONITOR) &&
              (phy->chandef.chan->flags & IEEE80211_CHAN_RADAR))
              return MT_DFS_STATE_ACTIVE;

          return MT_DFS_STATE_DISABLED;
      }

      if (!cfg80211_reg_can_beacon(hw->wiphy, &phy->chandef,
                                   NL80211_IFTYPE_AP))
          return MT_DFS_STATE_CAC;

      return MT_DFS_STATE_ACTIVE;
  }

Since the regulatory state is NL80211_DFS_UNSET, mt76 returns
MT_DFS_STATE_DISABLED before CAC handling.

I also instrumented the later MT7915 radar initialization functions:

  mt7915_dfs_init_radar_specs()
  mt7915_dfs_start_radar_detector()

These were not reached during the failing CAC attempt.

The observed flow is therefore:

  country IN
    -> DFS-UNSET
    -> mt76 returns MT_DFS_STATE_DISABLED
    -> radar detector/CAC is not started
    -> hostapd start_dfs_cac() fails

I reproduced this with:

  channel 100 / HT20
  channel 100 / HE80
  channel 52 / HT20

Non-DFS channel 157 works normally.

There is also an existing OpenWrt report with the same symptom:

  https://github.com/openwrt/openwrt/issues/20699

My questions are:

1. Is it intentional that India has DFS-required ranges but no
   DFS-FCC, DFS-ETSI, or DFS-JP region?

2. If NL80211_DFS_UNSET is intentional, how are drivers such as mt76
   expected to perform DFS CAC?

3. Is mt76 expected to disable DFS when the regulatory region is
   NL80211_DFS_UNSET?

4. Should the India regulatory entry be updated, or is there another
   intended mechanism for selecting the appropriate DFS radar profile?

I have not forced DFS-FCC, DFS-ETSI, or DFS-JP locally because I do not
want to select a radar profile without regulatory justification.

I can provide complete "iw reg get" output, "iw phy" output, hostapd
logs, and the temporary mt76 instrumentation patch if useful.

Thanks,
Ankit Dange