[BUG] Bluetooth: btmtk: MT7902 does not recover from firmware assert; subsys reset leaves the MCU unresponsive

[Ismail Tarim]

Hi,

On an MT7902 (USB 13d3:3579) the Bluetooth firmware asserts on its own
while the machine is idle, at irregular intervals of up to 17 days.
The three failures on 7.2.11 came 8.5 hours, 46 minutes and 12 hours
after a cold boot. After the assert the driver's reset fails and the
device drops off the USB bus. Nothing short of a full power drain
(AC unplugged, power button held) brings it back: warm reboot, S5,
rfkill, port power cycling, the ACPI _RST of the port, PCIe FLR/SBR
of the WiFi half and a WFSYS reset were all tried and none of them
recover it.

This report has three parts: the assert itself, an instrumented trace
of the reset, and a correction to something I wrote in an earlier
patch series.

Setup
-----
  Machine:   ASUS Vivobook Pro 16X (K3605ZV)
  Kernel:    7.2.11 (Arch), includes 59c3ee19ca88 and 21b50c24843b
  Firmware:  mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin,
             Build Time 20250826211444 (linux-firmware 20260916)

1. The assert
-------------
Twelve natural failures since 2026-08-03. Ten of them were captured
with devcoredump, and all ten carry the same assert:

  <ASSERT> ../bluetooth/system/debug/sys_log_interface_emi.c #811 -
    0, 0x6455, 0x1010707, 0xFF150001, rc=0, BTSYS, id=0x4 idle,
    irq=0x2, isr=0x929A5C (five dumps) / 0x929EEA (five dumps)

  Captured: 2026-08-24, 08-26, 09-12, 09-21, 10-05, 10-10, 10-18,
            10-21, 10-23, 10-25, on kernels from 7.1.8 to 7.2.11

The firmware is idle each time ("id=0x4 idle"); nothing on the host
side precedes it in the log. The full dumps (about 1 MB each) are
available on request.

2. What the reset does after the assert
---------------------------------------
I enabled dynamic debug for btmtk_usb_uhw_reg_read() and
btmtk_usb_subsys_reset() and then compared four natural failures,
2026-10-18 (7.2.6) and 10-21, 10-23, 10-25 (7.2.11), with a reset of
a healthy chip through /sys/class/bluetooth/hci0/reset, which reaches
the same btusb_mtk_reset() path. All four natural failures read
identically:

                              healthy chip     after natural assert
  reg 0x740003a0 (WDT)        0x00000000       0x00000001
  reg 0x74000024              0x00000000       0x00000000
  reg 0x74000308              0x00000000       0x00000000
  reg 0x70002610 (SUBSYS_RST) 0x00000000       0x00000000
  reg 0x70002510 (MISC)       0x00000500       0x00000500
  chip id read (0x70010200)   returns          times out (5.1 s)
  result                      re-enumerates,   descriptor read -110,
                              setup 121 ms     port gone

So the generic reset sequence works on a healthy MT7902, and every
uhw register access still answers after the assert. The RST_DONE bit
in MISC reads the same in both cases, so the "Reset timeout" check
cannot tell a failed reset from a good one here. What does fail is
the vendor read (request 0x63) of the chip id, which times out, and
from then on the device no longer answers descriptor reads. The WDT
register is the only value that differs.

The ~10 s between "Mediatek coredump end" and "Can't get device id"
that shows up on every failure is two USB control timeouts. A
function_graph trace of a triggered dump shows btusb_mtk_reset()
taking 10.47 s, of which usb_driver_release_interface() on the ISO
interface takes 5.35 s: the interface is in altsetting 1, so
usb_unbind_interface() issues SET_INTERFACE(0) to the dead device and
waits out the 5000 ms timeout. The id read accounts for the other
5.1 s. This only adds latency; it does not affect the outcome.

My question for MediaTek: once the firmware has asserted and the WDT
register at 0x740003a0 reads 1, is there a reset sequence that brings
the MT7902 Bluetooth MCU back without removing power? The current
sequence evidently is not enough in that state.

3. Corrections to my earlier series
-----------------------------------
In "Bluetooth: btmtk: fix subsystem reset error reporting" (v2,
https://lore.kernel.org/linux-bluetooth/20260815115624.8309-1-ismailtarim7@gmail.com/)
I got two things wrong, and I'd like to correct them on the list:

  - The cover letter cites an assert in
    system/rom/transport/tra_usb3.c #764 as the firmware failure. That
    assert is produced by triggering a coredump by hand through
    /sys/class/bluetooth/hci0/device/coredump (2 of 2 manual
    triggers). The natural failures assert in
    sys_log_interface_emi.c #811, as above.

  - Patch 1/2 describes the id read succeeding with an id of zero. In
    the natural failures the read times out instead, which the error
    branch already reported correctly before that patch. The patch is
    still correct for the zero-id case, but I had not observed that
    case, and the log line is identical for both.

Neither correction affects the merged code.

Thanks,
Ismail