[M0Rf30]

Three WCN3990 firmware workarounds needed for usable 5 GHz, reworked as ath10k firmware feature bits (per review) instead of QCA_REV_WCN3990() checks:

Bit	firmware-N.bin name	Effect
ATH10K_FW_FEATURE_NO_QUIET_MODE (23)	no-quiet-mode	skip pdev quiet mode cmd (fw crashes despite advertising WMI_SERVICE_THERM_THROT)
ATH10K_FW_FEATURE_NO_VHT_TXBF (24)	no-vht-txbf	strip VHT beamformer/beamformee caps (fw NULL-deref in wlan_txbfee_parse_gid)
ATH10K_FW_FEATURE_PASSIVE_SCAN_5GHZ (25)	passive-scan-5ghz	scan all 5 GHz channels passively (fw never tunes on active 5 GHz scan)

Enable with the matching ath10k-fwencoder update (qca-swiss-army-knife, also adds missing iram-recovery = 22):

ath10k-fwencoder --modify --features=wowlan,mgmt-tx-by-ref,non-bmi,no-quiet-mode,no-vht-txbf,passive-scan-5ghz firmware-5.bin

Note: firmware-5.bin is shared by all WCN3990 SoCs on SNOC, so the bits should ship in sdm660 device firmware packages rather than linux-firmware.

[minlexx]

These should go directly into ath10k list I believe. I'd like to see responses to it..

[barni2000]

These should go directly into ath10k list I believe. I'd like to see responses to it..

Also SoB-s are missing

[minlexx]

@M0Rf30 do these changes help specifically only for connecting to 5Ghz WI-Fi or do they also fix firmware crashes for "normal" one?

I just in general want to know more: how did you come to these conclusions, how did you trace the driver and which command causes which crash, etc

[M0Rf30]

2.4 GHz was always fine — it never exercised the broken paths. All three patches are about making 5
GHz actually usable, and they fix three separate WCN3990 firmware bugs:

1. quiet-mode skip (thermal.c) — the firmware crashes when ath10k sends the quiet-mode WMI command; it falsely advertises WMI_SERVICE_THERM_THROT, so the existing service-bit guard didn't catch it. This is a hard firmware crash on bring-up.
2. force passive scan on 5 GHz (mac.c) — the firmware never tunes the radio during active scan on 5
   GHz, so 5 GHz APs are simply never discovered.
3. disable VHT beamforming (wmi.c) — associating to a 5 GHz VHT AP that does MU-MIMO beamforming
   crashes the firmware.

How I traced it: I have two devices (tulip = c2-00538, jasmine = c2-00811) reachable over SSH/USB, so
I reproduced each crash live and read the firmware crash signature out of dmesg, e.g.:

  qcom-q6v5-mss 4080000.remoteproc: fatal error received:                                              
    err_qdi.c:459:EX:wlan_process:1:WLAN RT:207f:PC=b00c87e0                                           

The interesting one is 3. The crash PC was always 0xb00c87e0, so I pulled the running WLAN firmware
(/.../modem/image/wlanmdsp.mbn) and reversed it. It's a Qualcomm-signed Hexagon (QDSP6) image —
radare2 6.x has a Hexagon backend, so after extracting the R+X code segment (vaddr base 0xb0000000) I
disassembled around the crash offset:

  r2 -a hexagon -b 32 -c 's 0xc87c8; pd 80' code.bin                                                   

That packet is:

  R18 = memw(R0 + 0x14)        ; per-peer TxBF context pointer                                         
  ...                                                                                                  
  R3  = memw(R18 + 24)         ; <-- faults here (R18 == NULL), PC=0xb00c87e0                          

The rodata strings next to the function name it: wlan_txbf.c / wlan_txbfee_parse_gid — i.e. the VHT
(802.11ac) MU-MIMO transmit-beamforming Group-ID Management handler. It dereferences an uninitialised per-peer beamforming context. That's why it's 5 GHz-only (MU-MIMO beamforming is VHT, absent on the 2.4 GHz HT link) and regdomain-independent (I tested world vs a country reg domain — identical crash). wcn-3990-regdomain

The trigger is the AP sending a VHT Group ID Management action frame, which only happens if the STA
advertises beamformee support — so clearing the VHT beamformer/beamformee capability bits stops the AP from ever sending it, and the buggy path is never entered. VHT data rates are unaffected (still
associates at VHT80, MCS9).

I also checked whether a firmware update would fix it: disassembling jasmine's newer c2-00811 shows
the identical unguarded memw(R18+24) (at 0xb00ca330 there), and jasmine crashes the same way — so
there's no fixed firmware build to rely on, and the host-side workaround is needed unconditionally.
Firmware patching isn't an option either: androidboot.secureboot=1 and the modem is authenticated via
TrustZone PAS (MBA), so a modified wlanmdsp.mbn won't load.

[minlexx]

SInce this smells like fw-specific quirk, I think this should be implemented as another "firmware feature bits". Add it to struct ath10k_fw_features and to ath10k-fwencoder, naming it like ATH10K_FEATURE_BIT_PASSIVE_SCAN and checking feature bit if (test_bit(ATH10K_FEATURE_BIT_PASSIVE_SCAN, ar->running_fw->fw_file.fw_features)) ... like e.g. here

[okias]

Note: firmware-5.bin is shared by all WCN3990 SoCs on SNOC, so the bits should ship in sdm660 device firmware packages rather than linux-firmware.

then find a way how to detect it. it can be also device-tree quirk. In cases when it can't be auto-detected.
If the latest firmware (which not going to be updated by the vendor) has the problem, it's ok solution (just needs to be explicitly explained in the commit msg)

[minlexx]

Yeah, this looks a lot safer to limit to firmware fuatures. So far it seems that each device's firmware is unique snowflake (downstream seems to configure firmware capabilities in some vendor/etc/wifi/WCNSS_qcom_cfg.ini file), so in my view it's fine if each device provides its own "firmware discriptor" (firmware-5.bin).

We've found that possibly downstream's qcacld is parsing this INI file passed from some ioctl by userspace, but this needs to be verified..

@M0Rf30 maybe you can push your new fwencoder bits into https://github.com/sdm660-mainline/qca-swiss-army-knife for a while?

[M0Rf30]

Pushed the fwencoder bits to https://github.com/sdm660-mainline/qca-swiss-army-knife (master, 21f2e36). Bits are now sorted: 23 no-quiet-mode, 24 no-vht-txbf, 25 passive-scan-5ghz. Agree on per-device firmware-5.bin; I'll look into the WCNSS_qcom_cfg.ini / qcacld path to see if any of these map to an ini knob.

[M0Rf30]

@minlexx the line you linked is the PNO handler. qcacld reads the ini itself at init (cfg_parse("wlan/qca_cld/WCNSS_qcom_cfg.ini")), no ioctl.

From sdm660-common WCNSS_qcom_cfg.ini:

• gThermalMitigationEnable=0: downstream never sends quiet mode, so no-quiet-mode stays.
• gTxBFEnable=1, gEnableMuBformee=1: beamforming is on downstream. The difference is order. qcacld sets VDEV_PARAM_TXBF before peer assoc, ath10k sets it after. I'll test the reorder on jasmine; if it fixes the crash, no-vht-txbf goes away.
• Passive scan: downstream scans 5 GHz actively. Its start-scan always sets WMI_SCAN_ADD_OFDM_RATES; ath10k never does, and 5 GHz has only OFDM rates. I'll test that before keeping passive-scan-5ghz.

The quiet-mode and passive-scan workarounds were already posted by Malte Schababerle for SM8150: https://www.mail-archive.com/ath10k@lists.infradead.org/msg17637.html. Qualcomm asked for firmware dumps; nothing merged.

@okias c2-00811 is the latest firmware for these devices. I'll put that in the commit messages for whatever bits are left.

[minlexx]

qcacld reads the ini itself at init (cfg_parse("wlan/qca_cld/WCNSS_qcom_cfg.ini")), no ioctl.

Cool, good to know! Good luck with tests ;)