public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: LB F <goainwo@gmail.com>
To: Ping-Ke Shih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
Date: Sat, 14 Mar 2026 14:39:32 +0200	[thread overview]
Message-ID: <CALdGYqSq416qqqZ7t+wG5fir9NWfi3578+brdaj05q-42Gj14w@mail.gmail.com> (raw)
In-Reply-To: <CALdGYqRYVxGbg+qRNUvRNr9V4f2YVZ7p=amwq1ktdmZVkwxjQg@mail.gmail.com>

Ping-Ke Shih <pkshih@realtek.com> wrote:
> I'd adopt your suggestion (dynamic LPS_DEEP_MODE_NONE) if the test
> is positive.

Hi Ping-Ke,

Following your suggestion, I performed an additional experiment to
validate the dynamic LPS_DEEP_MODE_NONE idea. Please treat this
purely as a field test report -- I am not a kernel developer, and the
implementation below is certainly not upstream-quality. I am sharing
it only in the hope that it helps you design a proper solution.

What I did:

I extended your DMI quirk in pci.c with an additional capability flag
for LPS Deep mode. The only file touched was pci.c (your patch) --
main.c was left completely unmodified.

The changes to your patch are as follows:

  /* 1. Extended the capabilities enum */
  enum rtw88_quirk_dis_pci_caps {
          QUIRK_DIS_PCI_CAP_ASPM,
          QUIRK_DIS_PCI_CAP_LPS_DEEP,  /* test addition */
  };

  /* 2. Extended disable_pci_caps() callback */
  static int disable_pci_caps(const struct dmi_system_id *dmi)
  {
          uintptr_t dis_caps = (uintptr_t)dmi->driver_data;

          if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_ASPM))
                  rtw_pci_disable_aspm = true;

          if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_LPS_DEEP))
                  rtw_disable_lps_deep_mode = true;

          return 1;
  }

  /* 3. Both flags set for the HP P3S95EA#ACB entry */
  .driver_data = (void *)(BIT(QUIRK_DIS_PCI_CAP_ASPM) |
                          BIT(QUIRK_DIS_PCI_CAP_LPS_DEEP)),

I am aware that setting rtw_disable_lps_deep_mode from pci.c is
architecturally impure -- it is a global flag that would affect all
rtw88 devices in a hypothetical multi-adapter system. A proper
per-device solution (e.g. a flag inside struct rtw_dev set during
probe) would be cleaner. I simply used the existing global as the
most straightforward way to validate the concept.

Verification:

Confirmed no rtw88-related entries exist in /etc/modprobe.d/,
/lib/modprobe.d/, or /run/modprobe.d/, ruling out any external
parameter injection.

After loading the patched modules, the following was confirmed via
sysfs:

  /sys/module/rtw88_core/parameters/disable_lps_deep_mode = Y
  /sys/module/rtw88_pci/parameters/disable_aspm = Y

This confirms the DMI quirk is the sole source of both values.

Results (10-minute idle observation, battery power, wifi.powersave=3):

  With your ASPM patch alone (LPS Deep still active):
    - periodic "failed to send h2c command" bursts observed
    - occasional WiFi throughput drops and Bluetooth audio stuttering

  With ASPM patch + LPS Deep disabled via the quirk:
    - h2c=0, lps=0 across the entire observation window
    - WiFi throughput stable, Bluetooth audio uninterrupted

The result confirms that disabling LPS Deep Mode in addition to ASPM
completely eliminates the remaining firmware timeout loop on this
platform.

I hope this experiment is useful as a data point. Please feel free to
discard the implementation and design a proper solution -- I am ready
to test any updated patch you send.

Best regards,
Oleksandr Havrylov

  reply	other threads:[~2026-03-14 12:40 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 21:48 [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict) LB F
2026-03-10  2:02 ` Ping-Ke Shih
2026-03-10 11:01   ` LB F
2026-03-10 15:12     ` LB F
2026-03-11  2:20       ` Ping-Ke Shih
2026-03-11  2:15     ` Ping-Ke Shih
2026-03-11  2:22       ` Ping-Ke Shih
2026-03-11 11:00         ` LB F
2026-03-11 15:22           ` LB F
2026-03-12  1:56             ` Ping-Ke Shih
2026-03-12 21:42               ` LB F
2026-03-13  0:03                 ` LB F
2026-03-13  0:29                   ` LB F
2026-03-14 10:52                     ` LB F
2026-03-14 12:39                       ` LB F [this message]
2026-03-15  0:24                         ` LB F
2026-03-16  2:55                           ` Ping-Ke Shih
2026-03-16 20:27                             ` LB F
2026-03-17  1:28                               ` Ping-Ke Shih
2026-03-18  0:00                                 ` LB F
2026-03-18  0:58                                   ` Ping-Ke Shih
2026-03-18 23:55                                     ` LB F
2026-03-19  0:22                                       ` LB F
2026-03-19  0:49                                         ` Ping-Ke Shih
2026-03-19  1:24                                       ` Ping-Ke Shih
2026-03-19 23:58                                         ` LB F
2026-03-20  0:41                                           ` LB F
2026-03-20  1:00                                             ` Ping-Ke Shih
2026-03-20  1:19                                               ` LB F
2026-03-20  2:02                                                 ` Ping-Ke Shih
2026-03-21 12:07                                                   ` LB F
2026-03-23  2:01                                                     ` Ping-Ke Shih
2026-03-25 20:38                                                       ` LB F
2026-03-16  2:50                         ` Ping-Ke Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALdGYqSq416qqqZ7t+wG5fir9NWfi3578+brdaj05q-42Gj14w@mail.gmail.com \
    --to=goainwo@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pkshih@realtek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox