ath12k: QCN9274 hw2.0 single-band cards on IPQ9574 — firmware RDDM after WMI_INIT_CMD (WLAN.WBE.1.6-01243)

[insalata.fresca at gmail.com]

Hi Jeff, Raj Kumar, all,

I'm bringing up mainline OpenWrt on a Wallys DR9574 (IPQ9574 SoC + three
QCN9274 hw2.0 M.2 cards: one 2.4 GHz, one 5 GHz, one 6 GHz, all single-band,
all single-mac firmware). After working through two host-side bugs I've hit
what looks like a firmware crash and would appreciate guidance.

Hardware
--------
  Platform : Wallys DR9574 (Qualcomm AP-AL02-C4 reference design)
  SoC      : IPQ9574, soc_id 0x401a2200
  Cards    : 3x QCN9274 hw2.0 M.2 (DR9274-2GK / DR9274-5GK / DR9274-6GK)
  Firmware : WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 (linux-firmware 20260410)
             fw_version 0x160484db, built 2025-12-09 19:48
  Kernel   : 6.12.89 + ath12k from current ath-next + backports-6.18.26
  OTP      : slot 0001 board_id=0x1 (2.4 GHz card, programmed)
             slots 0002 0003 board_id=0xff (5/6 GHz cards, unprogrammed)

Two host-side fixes required (separate patches)
-----------------------------------------------

Fix A -- single-mac cards must not request WMI MAC1:

  Without: HTC service WMI MAC1 connect response: status: 0x1 (NOT_FOUND)
  Cause  : hw_params.max_radios=2 for qcn9274 hw2.0 unconditionally drives
           ath12k_htc_init() to open two WMI endpoints. Single-mac firmware
           (dualmac OTP bit clear) does not advertise the MAC1 WMI service.
  Fix    : read dualmac OTP at MHI register time; scope wmi_ep_count to 1
           when ab->dualmac is false for qcn9274 hw2.0.

Fix B -- DMA ring capability parser must tolerate unknown module IDs:

  Without: "Invalid module id 3" -> "failed to parse tlv -22" -> WMI ready timeout
  Cause  : WBE.1.6 sends capability entries for module_id 3 (and possibly
           others) the host enum does not know. ath12k_dp_get_ring_num()
           returns -EINVAL for unknown IDs, breaking TLV parsing entirely.
  Fix    : warn-and-skip on unknown module_id instead of returning -EINVAL.

Both confirmed working on this hardware. Happy to format as [PATCH ath-next] if
useful -- they get all three cards from "won't init" to "init proceeds cleanly
through WMI SVC_READY_EXT".

The blocker: firmware RDDM ~316 ms after host sends WMI_INIT_CMD
-----------------------------------------------------------------

With both fixes applied and CONFIG_ATH12K_DEBUG=y + debug_mask=0xffffff, boot
is clean through service negotiation:

  [19.482] Control service: ul pipe 0 dl pipe 1 eid 0 ready
  [19.485] HTT Data connect response: status: 0, assigned ep: 1
  [19.485] WMI connect response:      status: 0, assigned ep: 2
  [19.486] wmi_ext_service_bitmap 0x5e45be01 0x2d94d02 0x1c7010c6 0xee7d5c14
  [19.486] num hw modes 1  preferred_hw_mode 0
           slot 0002 (5/6 GHz): supported_bands 2  freq 5 GHz [4890-7125 MHz]
           slot 0001 (2.4 GHz): supported_bands 1  freq 2 GHz [2401-2495 MHz]
  [19.486] unsupported dma ring cap module id 3, skipping       (Fix B)
  [20.408] htc ep 2 consumed 1 credits (total 1)  <-- WMI_INIT_CMD sent
  [20.724] ath12k_pci 0003:01:00.0: mhi notify status reason MHI_CB_EE_RDDM
  [20.883] ath12k_pci 0001:01:00.0: mhi notify status reason MHI_CB_EE_RDDM
  [24.517] ath12k_pci 0002:01:00.0: failed to receive wmi unified ready event: -110

MHI_CB_EE_RDDM (RAM Dump Debug Mode) fires 316-476 ms after the host sends
WMI_INIT_CMD. The crash hits all three cards on every boot. Card 0002 does not
crash but times out waiting for WMI_UNIFIED_READY, presumably because the
firmware group is stuck.

I also attempted two host-side patches targeting the post-INIT path: a
NULL-ptr guard in ath12k_core_start and a DMA ring config timing fix in
ath12k_core_hw_group_start. Both were confirmed to have no effect -- RDDM fires
before either code path is reached, ruling out those theories.

A 21013-line verbose ath12k log (multiple consecutive boots) is available on
request.

Questions
---------

1. Is WLAN.WBE.1.6-01243 known to work with current ath-next on QCN9274 hw2.0
   single-band cards? Is there a known-good firmware version to try
   (WBE.1.4.x or WBE.1.3.x)?

2. Is the WMI_INIT_CMD payload format expected to differ between single-band
   and dual-band QCN9274 variants in a way current ath-next doesn't handle?

3. Is there a way to extract an RDDM dump after this crash (debugfs, PCIe BAR,
   MHI API) to identify the specific firmware fault?

4. Wallys vendor documentation says "only single band modules can work with
   current ath12k without extra development". My cards ARE single-band yet all
   three crash. Is there known additional host-side work beyond Fixes A and B?

Full verbose dmesg on request. Patches A and B are ready to post in proper
format if useful upstream.

Thanks,
Stefano