Potential firmware selection issue with QCNFA765 on ThinkPad P14s Gen 5

[Mohamed Sallam]

Hi ath11k maintainers,

I'm not very experienced with Linux - I'm an end user who noticed something
strange with my WiFi and wanted to share my findings in case it helps others.

Full disclosure: I used AI tools to help me investigate this issue and
understand the driver behavior. If I'm misunderstanding something fundamental,
please let me know.

WHAT I OBSERVED
===============
I have a Lenovo ThinkPad P14s Gen 5 AMD with a Qualcomm QCNFA765 WiFi card
(PCI ID 17cb:1103, subsystem 17aa:9309). I'm running Arch Linux with kernel
6.12.68-1-lts and firmware package linux-firmware-atheros 20260110-1.

I noticed that channels 149-165 in the 5 GHz band are marked with (no IR),
preventing me from using them. This happens consistently on my system.

WHAT I FOUND
============
While trying to understand why this happens, I discovered that the
linux-firmware package contains two different firmware files:
- Generic: ath11k/WCN6855/hw2.0/amss.bin
- Card-specific: ath11k/WCN6855/hw2.0/nfa765/amss.bin

When I manually create a symlink to use the nfa765 variant instead of the
default, the (no IR) restrictions disappear and all channels work normally.
This suggests the driver might not be selecting the optimal firmware for
this specific card variant.

The AI analysis suggested that:
- The driver looks for firmware at ath11k/<chip>/<hw_rev>/<filename>
- There's a "firmware-name" property that can override this, but it seems
to only work on ARM platforms with device trees, not x86 laptops
- The PCI subsystem ID (17aa:9309) might be available to the driver but
isn't being used to pick different firmware files

I don't know if this is accurate - it's just what the AI told me based on
looking at the driver code. The key point is that the firmware swap fixes
the issue for me.

REPRODUCTION STEPS
==================
On my system, with the default setup:
1. Check channel flags: iw phy | grep -E "5745|5765|5785|5805|5825"
2. Channels 149-165 show (no IR)

After applying the workaround (symlink nfa765 firmware):
1. Same check shows channels without (no IR) restrictions
2. WiFi works on all channels

TECHNICAL DETAILS
=================
Hardware: Lenovo ThinkPad P14s Gen 5 AMD (21ME001MUS)
WiFi: Qualcomm QCNFA765 (WCN6855 hw2.1)
PCI: 17cb:1103, subsystem 17aa:9309 (Lenovo)
Kernel: 6.12.68-1-lts
Firmware: linux-firmware-atheros 20260110-1
Firmware ver: WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41

Logs from my system:
$ dmesg | grep ath11k
[    2.845632] ath11k_pci 0000:02:00.0: chip_id 0x0 chip_family 0x0
board_id 0xff
[    2.845778] ath11k_pci 0000:02:00.0: fw_version 0x1019B0E1
fw_build_timestamp 2024-12-19
[    2.845789] ath11k_pci 0000:02:00.0: fw_build_id
WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
[    2.845806] ath11k_pci 0000:02:00.0: qmi failed to load bdf
[    2.845809] ath11k_pci 0000:02:00.0: qmi failed to load cal data,
fallback to 0xff

$ lspci -vnns 02:00.0
02:00.0 0280: 17cb:1103 (rev 01)
    Subsystem: 17aa:9309
    Kernel driver in use: ath11k_pci

With default firmware:
$ iw phy | grep -E "5745|5765|5785|5805|5825"
* 5745.0 MHz [149] (14.0 dBm) (no IR)
* 5765.0 MHz [153] (14.0 dBm) (no IR)
* 5785.0 MHz [157] (14.0 dBm) (no IR)
* 5805.0 MHz [161] (14.0 dBm) (no IR)
* 5825.0 MHz [165] (14.0 dBm) (no IR)

With nfa765 firmware symlinked:
* 5745.0 MHz [149] (23.0 dBm)
* 5765.0 MHz [153] (23.0 dBm)
* 5785.0 MHz [157] (23.0 dBm)
* 5805.0 MHz [161] (23.0 dBm)
* 5825.0 MHz [165] (23.0 dBm)

MY WORKAROUND
=============
I'm currently using this workaround:
  sudo ln -sf ../hw2.0/nfa765/amss.bin.zst \
      /lib/firmware/ath11k/WCN6855/hw2.1/amss.bin.zst

This fixes the issue for me, but I understand it's a hack, not a proper
solution.

QUESTIONS
=========
1. Is the driver supposed to automatically select card-specific firmware
   based on PCI subsystem ID, or is this working as designed?
2. If it's supposed to work this way, could there be a bug in the firmware
   path selection logic?
3. Is there a better workaround than manually symlinking firmware files?

Thank you for your time and for maintaining this driver. I appreciate
any guidance you can provide, even if it's just to tell me this is
expected behavior and I'm misunderstanding something.

Best regards,
Mohamed Sallam