Re: [BUG] rtw88_8723de: Wi-Fi and Bluetooth fail after warm reboot

Snake Pilot <[email protected]> Sat, 1 Aug 2026 02:00:12 -0600
Newsgroups org.kernel.vger.linux-usb,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless
Message-ID <CA+fxq6hD-duO3g1gEEQL5o+_S-y8dfFDerD58=scNsd9WfdU5Q@mail.gmail.com>
Hello Lovekesh,

Thank you for the diagnostic patch. I applied it to the Debian 7.1.3-1
source and rebuilt the affected bluetooth, btusb/btrtl, and rtw88 modules.
The test boot used kernel 7.1.3+deb14-amd64. The kernel taint was 12288 due
to the locally built, unsigned modules.

I started from a cold boot where both Wi-Fi and Bluetooth worked, disabled
the existing shutdown workaround for this reboot, and performed a normal
warm reboot to the same patched kernel.

The warm reboot reproduced both failures. At the actual warm shutdown
(01:35:26), the previous-boot journal shows that the Bluetooth core shutdown
path and Realtek callback did run and reported success:

  Bluetooth: hci0: diag: hci_dev_shutdown: HCI_UP=1 HCI_UNREGISTER=0
shutdown_cb=btrtl_shutdown_realtek [btrtl]
  Bluetooth: hci0: diag: calling vendor shutdown callback
  Bluetooth: hci0: diag: btrtl_shutdown_realtek: sending HCI_OP_RESET
  Bluetooth: hci0: diag: btrtl_shutdown_realtek: HCI_OP_RESET completed OK
  Bluetooth: hci0: diag: vendor shutdown returned 0

However, there is no `btusb: diag: device_shutdown()` message and no
`diag: btusb_disconnect` message in that boot journal.

While checking why the btusb shutdown message was absent, I noticed that
`usb_register_driver()` unconditionally assigns:

  new_driver->driver.shutdown = usb_shutdown_interface;

Therefore the diagnostic callback assigned through
`btusb_driver.driver.shutdown` is overwritten during USB driver registration.
USB interface drivers expose their own callback through the top-level
`struct usb_driver.shutdown` member instead (for example, uas_driver). A
follow-up diagnostic callback would need the `struct usb_interface *`
signature and this registration:

  static void btusb_shutdown(struct usb_interface *intf)
  ...
  .shutdown = btusb_shutdown,

This explains the missing btusb shutdown log, although it does not by itself
explain or fix the retained hardware state. I can test a corrected diagnostic
or a specific USB reset/shutdown sequence if useful.

For completeness, an identical successful HCI shutdown sequence also appears
once during initial boot at 01:30:57. The sequence at 01:35:26 is the one from
the tested warm shutdown.

On the next boot, Bluetooth again failed to enumerate with error -71. The
rtw88 diagnostic logging showed:

  rtw88_8723de 0000:02:00.0: diag: pre-toggle REG_SYS_PW_CTRL=0x12,
poll offset=0x5 want=0x0
  rtw88_8723de 0000:02:00.0: diag: post-toggle REG_SYS_PW_CTRL=0x1a,
retry poll read=0x01
  rtw88_8723de 0000:02:00.0: mac power on failed
  rtw88_8723de 0000:02:00.0: probe with driver rtw88_8723de failed
with error -16

No Wi-Fi interface was created and the Bluetooth USB interfaces were absent.
I had to use the 30-second complete power-off procedure to recover the combo
device afterward.

I attached `journal-kernel-previous.txt`, which is the requested complete
`journalctl -k -b -1` output. I also attached `journal-kernel-current.txt`
because it contains the rtw88 register diagnostics and the reproduced -71/-16
failures from the boot immediately following that shutdown.

Regards,
Snake

El vie, 31 jul 2026 a la(s) 2:30 p.m., Lovekesh Solanki
([email protected]) escribió:
>
> Thanks for additional testing and logs,
>
> On Fri, Jul 31, 2026 at 03:58:32AM -0600, Snake Pilot wrote:
> >   Module unloaded       Extra delay    Wi-Fi              Bluetooth
> >   ------------------------------------------------------------------------
> >   rtw88_8723de          0 seconds      failed (-16)       failed (-71)
> >   rtw88_8723de          1 second       failed (-16)       failed (-71)
> >   rtw88_8723de          3 seconds      failed (-16)       failed (-71)
> >   rtw88_8723de          5 seconds      failed (-16)       failed (-71)
> >
> >   btusb                 0 seconds      worked             worked
> >   btusb                 1 second       worked             worked
> >   btusb                 3 seconds      worked             worked
> >   btusb                 5 seconds      worked             worked
> I'd say this rules out anything in rtw88 and we should focus on btusb,
> since unloading it fixed both functions.
>
> > No Wi-Fi interface appeared, and Bluetooth remained absent. Thus, the PCI bus
> > reset did not recover the device after the failure had occurred.
> Yeah and with -71 above seems like chip isn't answering read descriptors
> at all.
>
> The previous boot journal there's no other bluetooth activity logged
> after boot, so a graceful bluetooth shutdown doesn't seem to be
> happening on a warm reboot, but it does work when you explicitely unbind
> it.
>
> Problem could be in the power state chip may be left in a state warm
> reboot cannot clear.
>
> A somewhat similar issue with the Qualcomm QCA6390 combo 7e7bbddd029b
> ("qca6390 enable failure after warm reboot"), where they fixed it by
> simply making sure chip got proper reset/shutdown command before
> restart. This could also work for our case but needs confirmation.
>
> I'm attaching a small patch that just adds extra logging around the
> shutdown path for this chip to see what's been invoked and what not
> before a warm reboot and if it even completes.
>
> Could you apply it and perform a simple warm reboot and send the
> journalctl -k -b -1 after it?
>
> Regards,
> Lovekesh
>
journal-kernel-previous.txt (text/plain, 107.3 KB) - not displayed
journal-kernel-current.txt (text/plain, 102 KB) - not displayed