[RFC] IPQ8074 v1 / Netgear RAX120 v1: interest in support and review prerequisites

[Zephyr Madera]

Hello ath11k maintainers,

Robert Marko suggested asking here whether there is interest in supporting
IPQ8074 v1 before preparing a formal support series. I own a Netgear
RAX120 v1 and have an experimental OpenWrt port developed with AI
assistance. I would like to make the useful source work available for
review, without presenting it as upstream-ready.

Linux socinfo on the unit reports:

    machine:  IPQ8074
    revision: 1.2
    soc_id:   323

In the OpenWrt discussion, Robert explained that this early silicon was
intentionally left unsupported, differs in peripherals and clocks, does
not comply with the final 802.11ax standard, and lacks publicly available
ath11k firmware. I understand that successful local bring-up does not
resolve those concerns.

The bring-up was rebased to OpenWrt main at:
    edc6b8f160c798cd211893bc5df25aec7cfca838

The tested base uses Linux 6.18.55 and mac80211 backports 7.2. On this one
unit, recorded checks include Q6 startup, both internal PHYs, LAN1
management, and four client cases: 2.4 GHz and 5 GHz with WPA2-PSK and
WPA3-SAE. Those cases covered association, LAN-side DHCP/DNS, ping and a
checksum-verified local HTTPS transfer. These are limited bring-up
results, not standards-conformance, sustained-load or cross-device
qualification.

The source work has been separated for discussion into:
- Two candidate generic ath11k parser corrections: host-sized MAC/PHY
  record allocation and bounds on READY MAC-address array reads.
- Secure WCSS separate-M3 loading and its binding, retaining PAS6.
- IPQ8074 v1 register/descriptor/ring handling and legacy firmware
  startup/event compatibility.
- Separate RAX120v1 board, image and upgrade integration.

The generic corrections have been checked against the pinned OpenWrt
wireless stack, but have not yet been rebased and validated against the
current upstream wireless tree. The v1 development sequence also needs
review and reduction.

The working setup depends on owner-retained HK1.2 firmware and this
unit's calibration. A public, repeatable firmware acquisition path and
redistribution terms are unresolved. Source provenance, attribution and
DCO certification also need completion before formal submission. No
firmware blobs, calibration data, private settings or flashable images
are attached.

Could you advise on three points?

1. Is there any interest in reviewing IPQ8074 v1 support, or do the
   hardware and firmware constraints make this unsuitable for upstream?
2. If there is interest, what minimum firmware availability and hardware
   evidence would you need, and which tree should the initial source
   series target?
3. Independently of v1 support, would it be useful to submit the generic
   parser corrections separately if they still apply to current upstream?

I can follow up with focused source-only patches and sanitized test
evidence. Local button and diagnostic customizations are separate from
this proposed hardware work. I have the router available for coordinated
testing, but cannot claim testing on other IPQ8074 revisions.

Thank you for helping establish whether there is a useful upstream path.

Regards,
John