[PATCH v2 0/2] Bluetooth: btmtk: fix subsystem reset error reporting

Two bugs in btmtk_usb_subsys_reset() that make it report success to its
caller when the subsystem reset has actually failed.

Patch 1 covers the case where the post-reset chip id reads back as zero:
the function logs "subsys reset fail." and then returns 0.

Patch 2 restores propagation of the MTK_BT_RST_DONE poll timeout, which
has been silently overwritten since commit 3dcb122b3064 ("Bluetooth:
btusb: mediatek: return error for failed reg access") started assigning
err at the chip id read.

Found while investigating an MT7902 [13d3:3579] whose controller stops
responding and never returns to the USB bus. On that device the failing
path can be reached on demand by requesting a coredump, since btmtk asks
for a reset once the dump completes:

  # echo 1 > /sys/class/bluetooth/hci0/device/coredump

The captured firmware coredump shows the controller asserting inside its
ROM rather than in the downloadable blob, which is consistent with the
failure surviving a firmware update:

  <ASSERT> system/rom/transport/tra_usb3.c #764 - BTSYS, id=0x4 idle

Both patches only correct the error reporting; neither changes the
recovery behaviour or makes that controller recoverable. They are a
prerequisite for anything that wants to react to a failed reset, since
today the failure is not visible to the caller.

Compile tested on x86_64 (W=1, no new warnings); checkpatch --strict clean.

Changes in v2:
- 1/2: shorten the subject so the CI gitlint check passes (was 81 > 80).
- 1/2: document how the failing path can be reached on demand.
- No functional change; the diff is identical to v1.

v1: https://lore.kernel.org/linux-bluetooth/[email protected]/

Ismail Tarim (2):
  Bluetooth: btmtk: Do not report success when subsys reset fails
  Bluetooth: btmtk: Do not discard the subsystem reset timeout

 drivers/bluetooth/btmtk.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)


base-commit: 15ef2f78c49d20d53ec7c0f1c9b40b02e089f2d6
-- 
2.55.0