MT76: MT7613 radio and DFS support

@ryderlee1110 Sorry for the aside, but I recently got a few devices with the MT7613BE radio, and that uses the same driver as the MT7615 radios (no idea if that implies any hardware similarity between both). However, there's no DFS support on MT7613 in mt76, whereas it is supported on MT7615. Felix was unsure as to why (whether it hadn't been tested or whether it had been causing problems). Would you have any insights? There's a few devices that are getting ported to OpenWrt at the moment, al with MT7613 radios, so would be neat if those could work with DFS as well.

2 Likes

I think it should work. Can you check if it goes to is_mt7663()?

Also, what's your firmware version?

Thanks! I have mediatek/mt7663pr2h_rebb.bin in /lib/firmware/ indeed. Latest OpenWrt master. By default hostapd just exits though if you specify a DFS channel:

Sun Feb  7 00:40:07 2021 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->COUNTRY_UPDATE
Sun Feb  7 00:40:07 2021 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->HT_SCAN
Sun Feb  7 00:40:07 2021 daemon.notice hostapd: wlan1: interface state HT_SCAN->DFS
Sun Feb  7 00:40:07 2021 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5260 chan=52 sec_chan=1, width=1, seg0=58, seg1=0, cac_time=60s
Sun Feb  7 00:40:07 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Sun Feb  7 00:40:07 2021 daemon.err hostapd: Interface initialization failed
Sun Feb  7 00:40:07 2021 daemon.notice hostapd: wlan1: interface state DFS->DISABLED
Sun Feb  7 00:40:07 2021 daemon.notice hostapd: wlan1: AP-DISABLED

If I understood it right, Felix told me earlier to replace the following:

$ git diff
diff --git a/mt7615/init.c b/mt7615/init.c
index e85568b..4ab5daf 100644
--- a/mt7615/init.c
+++ b/mt7615/init.c
@@ -344,7 +344,7 @@ mt7615_init_wiphy(struct ieee80211_hw *hw)
        hw->sta_data_size = sizeof(struct mt7615_sta);
        hw->vif_data_size = sizeof(struct mt7615_vif);
 
-       if (is_mt7663(&phy->dev->mt76)) {
+       if (mt7615_firmware_offload(phy->dev)) {
                wiphy->iface_combinations = if_comb;
                wiphy->n_iface_combinations = ARRAY_SIZE(if_comb);
        } else {
diff --git a/mt7615/mac.c b/mt7615/mac.c
index 9bae2f6..04dcd0d 100644
--- a/mt7615/mac.c
+++ b/mt7615/mac.c
@@ -2199,7 +2199,7 @@ int mt7615_dfs_init_radar_detector(struct mt7615_phy *phy)
        bool ext_phy = phy != &dev->phy;
        int err;
 
-       if (is_mt7663(&dev->mt76))
+       if (mt7615_firmware_offload(dev))
                return 0;
 
        if (dev->mt76.region == NL80211_DFS_UNSET) {

However, that seems to make the radio see radar events on channels where other APs are active. E.g. on channel 100, where other APs are listening on (so I presume there's no radar activity there):

Wed Feb 17 12:16:34 2021 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->HT_SCAN
Wed Feb 17 12:16:34 2021 daemon.err hostapd: could not get valid channel
Wed Feb 17 12:16:34 2021 daemon.notice hostapd: wlan1: interface state HT_SCAN->DFS
Wed Feb 17 12:17:20 2021 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=0 cf1=5500 cf2=0
Wed Feb 17 12:17:20 2021 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Wed Feb 17 12:17:20 2021 daemon.notice hostapd: wlan1: AP-DISABLED
Wed Feb 17 12:17:20 2021 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan1 wasn't started
Wed Feb 17 12:17:20 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
Wed Feb 17 12:17:20 2021 daemon.notice hostapd: wlan1: interface state DFS->DISABLED
Wed Feb 17 12:17:20 2021 daemon.notice hostapd: wlan1: interface state DISABLED->COUNTRY_UPDATE

This loops for a while, over and over again. Felix said even if DFS worked it still needed to be verified/certified (with an SDR simulating radar pulses etc).

1 Like

Exactly! Look like that version works for you, right?

There's a way for simple test. Please see my comments.
https://patchwork.kernel.org/project/linux-wireless/patch/0e4bcdda11b73ee7af17732dc847a4d6b06724c7.1561804422.git.lorenzo@kernel.org/
https://patchwork.kernel.org/project/linux-wireless/patch/33184e0b78983fe7c79fa70c5fbb21042aafa4f5.1561804422.git.lorenzo@kernel.org/

Format: pulse_start_time-pulse_width-pulse_power

1 Like

Sorry, I'm a bit lost. I looked at both patch sets, I see the DFS code made it into the driver, as well as the radar pattern simulation code. But how do I trigger it? I see related files in /sys/kernel/debug/ieee80211/phy1/mt76/. I see pulse_power and pulse_width e.g. are rw-, but radar_trigger is only -w-.

Do I need to write values to those files? If so, which ones?

Just feed radar pattern through those debugfs knobs in this format: pulse_start_time-pulse_width-pulse_power
Radar Pulse Pattern="3680128-2-245;3683878-2-245;3687628-2-245;3691378-2-245;3695128-2-245;3698878-2-245;3702628-2-245;3706378-2-245;3710128-2-245;3713878-2-245"

I don't mean to sound dumb but I am not seeing anything in debugfs where I can feed that into. dfs_hw_pattern is read-only. This is how debugfs looks for my device:

root@OpenWrt:/sys/kernel/debug/ieee80211/phy1/mt76# ls -l
-r--r--r--    1 root     root             0 Feb 15 22:02 acq
-r--------    1 root     root             0 Feb 15 22:02 ampdu_stat
-rw-------    1 root     root             0 Feb 15 22:02 chip_config
-rw-------    1 root     root             0 Feb 15 22:02 dbdc
-r--------    1 root     root             0 Feb 17 15:22 dfs_hw_pattern
-r--------    1 root     root             0 Feb 15 22:02 eeprom
-rw-------    1 root     root             0 Feb 15 22:02 ext_mac_addr
-rw-------    1 root     root             0 Feb 15 22:03 fw_debug
-rw-------    1 root     root             0 Feb 15 22:02 idle-timeout
-rw-------    1 root     root             0 Feb 15 22:02 led_active_low
-rw-------    1 root     root             0 Feb 15 22:02 led_pin
-r--------    1 root     root             0 Feb 15 22:02 otp
-rw-------    1 root     root             0 Feb 17 15:11 pattern_len
-rw-------    1 root     root             0 Feb 17 15:11 pulse_period
-rw-------    1 root     root             0 Feb 15 22:02 pulse_power
-rw-------    1 root     root             0 Feb 17 15:11 pulse_width
--w-------    1 root     root             0 Feb 17 14:48 radar_trigger
-r--r--r--    1 root     root             0 Feb 15 22:02 radio
-r--r--r--    1 root     root             0 Feb 15 22:02 rate_txpower
-rw-------    1 root     root             0 Feb 15 22:02 regidx
-rw-------    1 root     root             0 Feb 15 22:02 regval
--w-------    1 root     root             0 Feb 15 22:02 reset_test
-rw-------    1 root     root             0 Feb 15 22:02 rf_regidx
-rw-------    1 root     root             0 Feb 15 22:02 rf_regval
-rw-------    1 root     root             0 Feb 15 22:02 rf_wfidx
-rw-------    1 root     root             0 Feb 15 22:02 runtime-pm
-r--r--r--    1 root     root             0 Feb 15 22:02 rx-queues
-rw-------    1 root     root             0 Feb 15 22:02 scs
-r--r--r--    1 root     root             0 Feb 15 22:02 temperature
-r--r--r--    1 root     root             0 Feb 15 22:02 xmit-queues

I suppose I need to feed the three values together (pulse_start-time-pulse_width-pulse_power - e.g. 3680128-2-245 like you suggested) into a single file? Which one would that be? radar_trigger only seems to take 0 or 1.

-rw------- 1 root root 0 Feb 17 15:11 pulse_period
-rw------- 1 root root 0 Feb 15 22:02 pulse_power
-rw------- 1 root root 0 Feb 17 15:11 pulse_width
You can grep mt7615_mcu_rdd_send_pattern() to see how it works. BTW. I'm not sure if this works for mt7613 since command may change among chipsets.

Have you ever seen radar event (mt7615_mcu_rx_radar_detected())?

OK thanks, I'll whip up a small script to feed into those files.

No I haven't. Any debug flag I have to set to see such messages if that would occur?

I think the current dfs code needs to be reworked to adapt 7613.

OK. Do you still want me to try the radar event simulation or it that of little use at this point?

I took a look at MT7613 DFS and there was a minor design change compares to MT7615. I think it's not too hard to rework, but not sure if I have time ... Or, you can take a look at MT7915 DFS that is almost the same as MT7613.

4 Likes

My C skills are close to non-existent unfortunately. Thanks for the help and the insights already though.

2 posts were split to a new topic: MT7915 and DFS support