Re: [PATCH v2] wifi: ath11k: apply existing PM quirk to ThinkPad P14s Gen 5 AMD

Kyle Farnung <[email protected]>
Newsgroups org.infradead.lists.ath11k,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless,org.kernel.vger.stable
Message-ID <CAOPSVF04q6uvVdq8GTRLHBrVMdpt9=o9wVcFMc6f-yhmSBcZqQ@mail.gmail.com>
On Mon, Apr 13, 2026 at 11:43 PM Baochen Qiang
<[email protected]> wrote:
>
>
>
> On 4/1/2026 11:48 AM, Kyle Farnung wrote:
> > On Tue, Mar 31, 2026 at 7:08 PM Baochen Qiang
> > <[email protected]> wrote:
> >>
> >>
> >>
> >> On 3/31/2026 2:32 PM, Kyle Farnung via B4 Relay wrote:
> >>> From: Kyle Farnung <[email protected]>
> >>>
> >>> Some ThinkPad P14s Gen 5 AMD systems experience suspend/resume
> >>> reliability issues similar to those reported in [1]. These platforms
> >>
> >> how similar it is? can you describe the issue in details?
> >
> > The issue is that intermittently after suspend my WiFi adapter connects
> > successfully for a few minutes and then drops. It will then keep trying to
> > reconnect in a loop but never succeed. A reboot will fix it, but eventually
> > I found that reloading the module also resolves the issue
> > (modprobe -r ath11k_pci && modprobe ath11k_pci). Based on some searching, I
> > did try adding "ath11k_pci.disable_idle_ps=1" to my kernel arguments. At
> > first it looked like maybe it worked, but then I hit the same problem
> > again. At that point I decided to try building a custom module with the
> > ATH11K_PM_WOW override and so far I'm two days and 10 suspends in without
> > issue.
> >
> > Looking through kernel logs, the issue appears to have started with kernel
> > version 6.17.4. It looks like my Fedora install jumped from 6.16.10 to
> > 6.17.4 on October 22, 2025 and I started seeing the issue two days later.
> >
> > Here are the logs from the most recent occurrence (filtered for brevity):
> >
> > Mar 29 15:26:24 kjfp14sg5 kernel: PM: suspend exit
> > Mar 29 15:26:24 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: chip_id
> > 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
> > Mar 29 15:26:24 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: fw_version
> > 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id
> > WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
> > Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> > Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> > Mar 29 15:26:30 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=US
> > Mar 29 15:26:35 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-CONNECTED - Connection to 68:d7:9a:2a:94:f8 completed [id=0
> > id_str=]
> > Mar 29 15:26:49 kjfp14sg5 wpa_supplicant[2373]: wlp2s0: CTRL-EVENT-BEACON-LOSS
>
> this is the reason to your disconnection
>
> > Mar 29 15:26:55 kjfp14sg5 kernel: ath11k_pci 0000:02:00.0: failed to
> > flush transmit queue, data pkts pending 9
> > Mar 29 15:26:55 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:2a:94:f8 reason=4
> > locally_generated=1
> > Mar 29 15:27:00 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-DISCONNECTED bssid=80:2a:a8:98:26:3e reason=6
> > Mar 29 15:27:05 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-DISCONNECTED bssid=74:ac:b9:df:54:36 reason=6
> > Mar 29 15:27:09 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-DISCONNECTED bssid=68:d7:9a:2a:94:f8 reason=2
> > Mar 29 15:27:09 kjfp14sg5 wpa_supplicant[2373]: wlp2s0:
> > CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Batman" auth_failures=1
> > duration=10 reason=CONN_FAILED
>
> and the bssid is disabled so association to this AP won't happen in a period.
>
> Anyway, although it works, using the PM quirk seems not the right fix. As you mentioned it
> seems like a regression starting to show in 6.17.4, can you do regression test to locate
> the issue commit?

It took a bit of trial and error, but I'm reasonably confident that [3] is
the culprit. The issue is pretty sporadic, but I've been able to reproduce
it twice in ~50 sleep/wake cycles on that commit, while the immediate
ancestor has been clean for 17 cycles so far. I'll continue testing and
report back.

The change looks suspicious as it modifies a code path that runs on every
sleep/wake cycle, and the failure appears to be some sort of corrupted
firmware state. In a couple of cases the WiFi firmware crashed outright
(MHI_CB_EE_RDDM) while the issue was occurring.

[3] 79266fd78df1 ("wifi: ath11k: HAL SRNG: don't deinitialize and
re-initialize again")

>
> >
> >>
> >>> were not previously included in the ath11k PM quirk table.
> >>>
> >>> Add DMI matches for product IDs 21ME and 21MF to apply the existing
> >>> ATH11K_PM_WOW override, improving suspend/resume behavior on these
> >>> systems.
> >>>
> >>> Tested on a ThinkPad P14s Gen 5 AMD (21ME) running 6.19.9.
> >>>
> >>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
> >>> [2] https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-p-series-laptops/thinkpad-p14s-gen-5-type-21me-21mf/
> >>>
> >>> Fixes: ce8669a27016 ("wifi: ath11k: determine PM policy based on machine model")
> >>> Cc: [email protected]
> >>> Signed-off-by: Kyle Farnung <[email protected]>
> >>> ---
> >>> Changes in v2:
> >>> - Fix missing mailing list recipients (linux-wireless, ath11k, linux-kernel)
> >>> - Link to v1: https://lore.kernel.org/r/[email protected]
> >>> ---
> >>>  drivers/net/wireless/ath/ath11k/core.c | 14 ++++++++++++++
> >>>  1 file changed, 14 insertions(+)
> >>>
> >>> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> >>> index 3f6f4db5b7ee1aba79fd7526e5d59d068e0f4a2e..21d366224e75904feeae6cb9c93d9ef692d127fe 100644
> >>> --- a/drivers/net/wireless/ath/ath11k/core.c
> >>> +++ b/drivers/net/wireless/ath/ath11k/core.c
> >>> @@ -1041,6 +1041,20 @@ static const struct dmi_system_id ath11k_pm_quirk_table[] = {
> >>>                       DMI_MATCH(DMI_PRODUCT_NAME, "21D5"),
> >>>               },
> >>>       },
> >>> +     {
> >>> +             .driver_data = (void *)ATH11K_PM_WOW,
> >>> +             .matches = { /* P14s G5 AMD #1 */
> >>> +                     DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> >>> +                     DMI_MATCH(DMI_PRODUCT_NAME, "21ME"),
> >>> +             },
> >>> +     },
> >>> +     {
> >>> +             .driver_data = (void *)ATH11K_PM_WOW,
> >>> +             .matches = { /* P14s G5 AMD #2 */
> >>> +                     DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
> >>> +                     DMI_MATCH(DMI_PRODUCT_NAME, "21MF"),
> >>> +             },
> >>> +     },
> >>>       {}
> >>>  };
> >>>
> >>>
> >>> ---
> >>> base-commit: dbd94b9831bc52a1efb7ff3de841ffc3457428ce
> >>> change-id: 20260330-p14s-pm-quirk-0a51ba19235f
> >>>
> >>> Best regards,
> >>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.