[Bug 210141] New: Bluetooth device rtw_8822ce is lost after suspend to RAM

[Bug 210141] New: Bluetooth device rtw_8822ce is lost after suspend to RAM

[bugzilla-daemon]

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

            Bug ID: 210141
           Summary: Bluetooth device rtw_8822ce is lost after suspend to
                    RAM
           Product: Drivers
           Version: 2.5
    Kernel Version: 5.9.7
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: blocking
          Priority: P1
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: funtoos@yahoo.com
        Regression: No

This is on an HP 14" laptop model: HP 14-dq1xxx with rtw_8822ce driver drives
the wifi and bluetooth.

So, everything works fine until I suspend to RAM. After waking from suspend,
the bluetooth adapter just disappears. I can see in the 'dmesg' the USB device
gets disconnected but no reason is mentioned.

Before suspend:

[    6.937836] usb 1-10: new full-speed USB device number 5 using xhci_hcd
[    7.065627] usb 1-10: New USB device found, idVendor=0bda, idProduct=b00c,
bcdDevice= 0.00
[    7.065630] usb 1-10: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[    7.065632] usb 1-10: Product: Bluetooth Radio 
[    7.065633] usb 1-10: Manufacturer: Realtek

After resume, it is gone:

[  329.512699] Restarting tasks ... done.
[  329.515898] usb 1-10: USB disconnect, device number 5
[  329.585469] PM: suspend exit
[  329.585559] elogind-daemon[7406]: System resumed.

# lspci
00:00.0 Host bridge: Intel Corporation Device 8a02 (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics G1 (Ice
Lake) (rev 07)
00:04.0 Signal processing controller: Intel Corporation Device 8a03 (rev 03)
00:14.0 USB controller: Intel Corporation Ice Lake-LP USB 3.1 xHCI Host
Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Device 34ef (rev 30)
00:15.0 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO
I2C Controller #0 (rev 30)
00:15.1 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO
I2C Controller #1 (rev 30)
00:16.0 Communication controller: Intel Corporation Management Engine Interface
(rev 30)
00:17.0 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller
[RAID mode] (rev 30)
00:1c.0 PCI bridge: Intel Corporation Device 34bf (rev 30)
00:1f.0 ISA bridge: Intel Corporation Ice Lake-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Smart Sound Technology Audio Controller
(rev 30)
00:1f.4 SMBus: Intel Corporation Ice Lake-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP SPI
Controller (rev 30)
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac
PCIe Wireless Network Adapter

# lsusb
Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 13d3:56c9 IMC Networks HP TrueVision HD Camera
Bus 001 Device 008: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 007: ID 413c:2011 Dell Computer Corp. Multimedia Pro Keyboard
Bus 001 Device 006: ID 413c:1005 Dell Computer Corp. Multimedia Pro Keyboard
Hub
Bus 001 Device 004: ID 0c45:64ab Microdia Integrated Camera
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Device 5 is gone from lsusb.

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

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

[bugzilla-daemon]

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

ericlevy@gmail.com changed:

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

--- Comment #2 from ericlevy@gmail.com ---
Confirmed. Same problem using RTL8821CE under Mint 2.0 kernel 5.8.0-31.


Would be nice if a workaround might be identified, in advance of a fix.
Currently I am rebooting whenever I need to regain use of bluetooth.

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

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

[bugzilla-daemon]

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

Marcos Sánchez Provencio (raptopassion@gmail.com) changed:

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

--- Comment #3 from Marcos Sánchez Provencio (raptopassion@gmail.com) ---
I have the same problem on an HP Laptop 15s-fq1xxx (10B51EA#ABE) with ubuntu
20.04 hwe (5.8.0-41-generic)

Bluetooth does not survive suspend; it does survive hibernate, in case it is
any hint.

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

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

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

[bugzilla-daemon]

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

stimucou12 (stiltskin@ymail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stiltskin@ymail.com

--- Comment #4 from stimucou12 (stiltskin@ymail.com) ---
The problem vanished away for me on HP Laptop 17-by0xxx running ubuntu 20.04
with kernel 5.4.0-91-generic and RTL8821CE using rtl8821ce-dkms
5.5.2.1-0ubuntu4~20.04.4

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

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

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

[bugzilla-daemon]

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.