Wcn3680 cannot search for 5ghz wifi

We replaced db4’s wifi chip with wcn3680, which itself supports 5ghz. When we adapt to version 17.09, we can search for 5ghz, and then upgrade to 19.01, the board cannot recognize 5g wifi. Has anyone ever encountered this situation? What do you need to change about the kernel? Give me some advice. Any idea will do. Thank you
Here’s the partial log

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
[ 12.296377] msm 1a00000.mdss: loaded qcom/a300_pm4.fw from legacy location
[ 12.296767] msm 1a00000.mdss: loaded qcom/a300_pfp.fw from legacy location
root@linaro-alip:~# [ 16.354602] qcom_wcnss_ctrl remoteproc0:smd-edge.WCNSS_CTRL.-1.-1: expected cold boot completion
[ 16.389219] Bluetooth: Core ver 2.22
[ 16.389559] NET: Registered protocol family 31
[ 16.391942] Bluetooth: HCI device and connection manager initialized
[ 16.396163] Bluetooth: HCI socket layer initialized
[ 16.400558] wcn36xx: mac address: 02:00:ab:6e:5a:01
[ 16.402675] Bluetooth: L2CAP socket layer initialized
[ 16.402709] Bluetooth: SCO socket layer initialized
[ 16.407700] can get iris wcn3680
[ 16.422105] NL80211_BAND_5GHZ
[ 16.453399] btqcomsmd a204000.wcnss:smd-edge:wcnss:bt: BD address 02:00:ab:6e:5a:00 retrieved from device-tree
[ 16.519895] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 16.648280] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 16.648304] Bluetooth: BNEP filters: protocol multicast
[ 16.652736] Bluetooth: BNEP socket layer initialized
[ 18.562604] Bluetooth: hci0 command 0xfc0b tx timeout
[ 18.682635] Bluetooth: RFCOMM TTY layer initialized
[ 18.682681] Bluetooth: RFCOMM socket layer initialized
[ 18.686336] Bluetooth: RFCOMM ver 1.11
[ 19.932501] wcn36xx: firmware WLAN version ‘WCN v2.0 RadioPhy vIris_TSMC_3.0 with 48MHz XO’ and CRM version ‘CNSS-PR-2-0-1-2-c1-74-130449-3’
[ 19.932536] wcn36xx: firmware API 1.5.1.2, 41 stations, 2 bssids
[ 19.955744] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 19.993461] alloc_contig_range: [beca0, beca5) PFNs busy
[ 20.285652] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 20.453649] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 39.782756] Seconds value to be written to RTC = 1574989759
[ 365.349655] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 681.360969] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 709.764341] Seconds value to be written to RTC = 1574990429
[ 997.342501] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 1313.329038] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 1382.765240] Seconds value to be written to RTC = 1574991102
[ 1629.375143] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

5GHZ has never been tested because it’s not supported on dragonboard 410c with wcn3620. First check you have the correct wcn3680 value in your device tree iris node: msm8916.dtsi « qcom « dts « boot « arm64 « arch - working/qualcomm/kernel.git - Qualcomm Landing Team kernel

This will alllow you to operate on 5GHz.

I’ve also heard that scan offload was not supported as is with 5Ghz (patch is welcome), so would suggest to try disabling scan offload and relies on software/manual scan for now:
https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/drivers/net/wireless/ath/wcn36xx/main.c?h=release/qcomlt-4.14#n677

Thank you very much for your reply. After comparing relevant documents and DTS, I found that there was no difference in essence. Then, the whole wcn36xx file in the kernel of 17.09 version was replaced with the wcn36xx file in the kernel of 17.09 version. After reloading the driver, it was found that 5ghz wifi could be recognized.I found that part of the files were changed between the two versions by comparison. What influence might have caused wcn3680 to fail to detect 5ghz wifi

Hi @sherluo

I would suspect an antenna matching problem. The DragonBoard 410c PCB was designed strictly for 2.5GHz (not 5GHz) so I would suspect that the antenna design and the matching components were never optimised for operation in both bands. after changing the chip, you really need an RF expert (Not me :wink: ) to take a look at the RF path. Everything between the WCN and the APQ should be fine with 5GHz.

I am surprised it doesn’t work at all, I think it should work, but just have very poor range.

-L-

1 Like

It’s due to the hardware offloaded scan support, which let the chip perform the scan on various channels. This allows a smoother scan, but this has never been tested with 5GHz (maybe there is something to do here). By using the old driver you just removed this feature and enabled software driven scan, which works but cause the regular connection to be suspended during the scan (1~3s) which can lead to latency drop, disconnection, etc… (NetworkManager triggers scan frequently).