Re: Potential firmware selection issue with QCNFA765 on ThinkPad P14s Gen 5

On 2/4/2026 2:54 AM, Mohamed Sallam wrote:
> 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.
> 

Thanks for reporting. This seems like a known issue and I have notified the dev team to
look into this. Likely we need to upload a new firmware to fix this, but I am not totally
sure now.

> Best regards,
> Mohamed Sallam
>