There have been a few requests here and on IRC, luckily I am revisiting 5.15 for both Debian and OpenWrt at the moment
The good news is that QCN9074 (e.g WLE3000H5) works without any special CMA settings with the latest available firmware. But there are some other issues you will encounter.
You can get the kernel package from:
echo 'deb [trusted=yes] https://archive.traverse.com.au/pub/traverse/debian-experimental/ lts-5-15 main' > /etc/apt/sources.list.d/traverse.list
apt get update && apt-get install linux-image-traverse
or
This should give you:
$ uname -a
Linux ath11ktest 5.15.37-traverse-lts-5-15+72-00004-g9bab92335e99 #1 SMP Tue May 3 11:12:07 UTC 2022 aarch64 GNU/Linux
The configuration and scripts used to build these debs are here: Files · lts-5-15 · traversetech / traverse-kernel-patches · GitLab
Warning: due to an lock / hang issue with SFPs and >=5.15, you will need to ensure your SFP ports are in legacy mode (even if you don’t have SFPs installed):
# In U-Boot, stop the boot process and enter:
setenv sfpmode legacy
saveenv
You will need these firmware files (SHA256 supplied to be sure):
/lib/firmware/ath11k/QCN9074/hw1.0/m3.bin 6bad938141e5ef3931eb84747935a3fb4cf954ee1720e66bc517f8a2f262b8ae
/lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin dbf0ca14aa1229eccd48f26f1026901b9718b143bd30b51b8ea67c84ba6207f1
/lib/firmware/ath11k/QCN9074/hw1.0/amss.bin 4b03e776e3392e249a9f5d9753be980cab287168f059861618618d65df016513
m3.bin and amss.bin come from ath11k-firmware/QCN9074/hw1.0/2.5.0.1/WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 at master · kvalo/ath11k-firmware · GitHub
board-2.bin comes from the top level hw1.0 directory in that repository
You should see this probe message from the kernel:
[ 12.712421] ath11k_pci 0001:04:00.0: Adding to iommu group 6
[ 12.724655] ath11k_pci 0001:04:00.0: BAR 0: assigned [mem 0x2840000000-0x28401fffff 64bit]
[ 12.738482] ath11k_pci 0001:04:00.0: qcn9074 hw1.0
[ 13.143949] ath11k_pci 0001:04:00.0: chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff
[ 13.152775] ath11k_pci 0001:04:00.0: fw_version 0x250a04b8 fw_build_timestamp 2021-12-20 06:41 fw_build_id
A quick sanity check:
ifconfig wlan0 up
iw dev wlan0 scan
You can try this hostapd config, but it doesn’t enable the full capabilities of the card. (This is something OpenWrt is much better at):
driver=nl80211
interface=wlan0
ssid=qcntest
country_code=AU # change this as appropriate
hw_mode=a
channel=149
chanlist=149
wmm_enabled=1
ieee80211n=1
ieee80211ac=1
ieee80211ax=1
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
wpa_passphrase=test12345 # change me
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][DSSS_CCK-40]
vht_oper_chwidth=0
vht_oper_centr_freq_seg0_idx=
vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][SU-BEAMFORMER][SU-BEAMFORMEE][MU-BEAMFORMEE][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC-1][MAX-A-MPDU-LEN-EXP7]
Known issue: when an ath11k pcie card is active, there will be a kernel oops when trying to shutdown or reboot. (In other words, do not run this on a remote system!)
[ 1030.452510] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x260011, cbfrsynra=0x80d, cb=6
[ 1030.470542] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x260011, cbfrsynra=0x80d, cb=6
[ 1030.480517] Internal error: synchronous external abort: 96000210 [#1] SMP
[ 1030.488713] Modules linked in: michael_mic qrtr_mhi caam_jr crypto_engine qrtr ns ath11k_pci ath11k qmi_helpers mac80211 crct10dif_ce sp805_wdt cfg80211 rfkill mhi tpm_i2c_atmel tpm caam rng_core qoriq_thermal qoriq_cpufreq fuse ip_tables sfp rtc_fsl_ftm_alarm i2c_mux_pca954x gpio_keys mdio_i2c
[ 1030.514835] CPU: 4 PID: 1 Comm: systemd-shutdow Not tainted 5.15.37-traverse-lts-5-15+71 #1
[ 1030.523183] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2022.04-rc5-00012-gd20cefe60c-dirty 04/01/2022
[ 1030.533962] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1030.540919] pc : ath11k_pci_read32+0x148/0x270 [ath11k_pci]
[ 1030.546494] lr : ath11k_pci_clear_dbg_registers+0x30/0x17c [ath11k_pci]
It is my understanding that there are bugs in the kernel’s MHI bus code which are being exposed by the LS1088’s IOMMU (we might be the only system MHI/ath11k is running on with IOMMU and/or strict (per PCIe controller) grouping?). Once I have more info we will see how best to get it fixed.