[Bug 210141] Bluetooth device driven by rtw_8822ce is lost after suspend to RAM

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=210141

pseudo-mors (bgnytyt65@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bgnytyt65@gmail.com

--- Comment #5 from pseudo-mors (bgnytyt65@gmail.com) ---
Root cause found + workaround (HP 15s-fq1xxx, Realtek RTL8821CE, BT 0bda:b00a).

Tested on: HP 15s-fq1120ur (SKU 286V9EA), DMI board 86C9, BIOS F.30, kernel
7.2.11.

Cause: this is a BIOS problem, not a btusb/firmware/USB problem. The Bluetooth
half of the M.2 card has its own enable line (W_DISABLE2# / BT_EN), driven by a
PCH GPIO pad. In the DSDT the BIOS sets this pad to 1 in only two places:
  - at boot, in \_SB.WLBT._STA (HPQ6001): SGOV (0x06010012, One)
  - on the airplane-mode key (EC query handler)
Nothing sets it on resume from S3. After S3 the pad comes back as 0, the
Bluetooth function stays powered off and drops off USB ("usb 1-10: USB
disconnect" right after "Waking up from system sleep state S3"). Wi-Fi is on
PCIe and on a different pad, so it comes back fine. This also explains why
hibernation "fixes" it: resume from S4 goes through a full BIOS boot.

Proof: after a broken resume, \_SB.GGOV 0x06010012 returns 0x0. Setting it to 1
brings the adapter back on USB within 1 second, no reboot. USB/xHCI resets, PCI
remove/rescan, secondary bus reset, link disable, driver reloads and
btusb/rtw88 options all fail because none of them touch that line.

Workaround (acpi_call + systemd-sleep hook), with raw commands and a long
warning first:
https://github.com/k0kfjjfkdjf/hp-laptop-15s-fq1xxx-fq1120ur-icelake-realtek-rtl8821c-rtl8821ce-bluetooth-after-suspend-fix#warning

PLEASE read the warning before trying it. The pad number comes from this
specific DSDT. On other models (14-dq1xxx, 17-by0xxx, ...) it may be a
different pin, and writing to a wrong GPIO pad is not safe. Check board/BIOS
first, read the pin before writing, and only continue if it reads exactly
0x0 or 0x1. The README explains how to find the right pad in your own DSDT
(look for the SGOV call in \_SB.WLBT._STA).

A proper kernel fix would probably be for hp-wmi (or a DMI quirk) to restore
the
Bluetooth enable state on resume, similar to what toshiba_bluetooth does for
Toshiba.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.