Wifi 5Ghz enablement

[M0Rf30]

No description provided.

[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.