All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/2] Bluetooth: btmtk: fix subsystem reset error reporting
@ 2026-08-15 11:56 Ismail Tarim
  2026-08-15 11:56 ` [PATCH v2 1/2] Bluetooth: btmtk: Do not report success when subsys reset fails Ismail Tarim
  2026-08-15 11:56 ` [PATCH v2 2/2] Bluetooth: btmtk: Do not discard the subsystem reset timeout Ismail Tarim
  0 siblings, 2 replies; 5+ messages in thread
From: Ismail Tarim @ 2026-08-15 11:56 UTC (permalink / raw)
  To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
  Cc: Jing Cai, Sean Wang, Chris Lu, linux-mediatek, linux-kernel,
	Ismail Tarim

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/20260815110119.11301-1-ismailtarim7@gmail.com/

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


^ permalink raw reply	[flat|nested] 5+ messages in thread
* [PATCH 1/2] Bluetooth: btmtk: Fix btmtk_usb_subsys_reset() reporting success on failure
@ 2026-08-15 11:01 Ismail Tarim
  2026-08-15 11:35 ` Bluetooth: btmtk: fix subsystem reset error reporting bluez.test.bot
  0 siblings, 1 reply; 5+ messages in thread
From: Ismail Tarim @ 2026-08-15 11:01 UTC (permalink / raw)
  To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
  Cc: Jing Cai, Sean Wang, Chris Lu, linux-mediatek, linux-kernel,
	Ismail Tarim

btmtk_usb_subsys_reset() validates the subsystem reset by reading the
chip id back. When that read succeeds at the bus level but yields an id
of zero, the reset has demonstrably not taken effect: the function logs
"Can't get device id, subsys reset fail." and then returns the return
value of btmtk_usb_id_get(), which in that case is zero, i.e. success.

btusb_mtk_reset() returns that value unchanged, so its caller cannot
tell a completed reset from a failed one.

Return -ENODEV when the chip id reads back as zero, leaving the existing
MT6639 exemption intact.

Observed on an MT7902 [13d3:3579] where the controller firmware asserts
and the subsequent subsystem reset fails, yet the driver continues as if
the reset had succeeded:

  Bluetooth: hci0: Mediatek coredump end
  Bluetooth: hci0: Can't get device id, subsys reset fail.
  usb 3-10: reset high-speed USB device number 5 using xhci_hcd
  usb 3-10: device descriptor read/64, error -110
  usb usb3-port10: attempt power cycle
  usb usb3-port10: unable to enumerate USB device

Note that this corrects the error reporting only; it does not by itself
make the controller recoverable in the case above.

Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work")
Signed-off-by: Ismail Tarim <ismailtarim7@gmail.com>
---
 drivers/bluetooth/btmtk.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 66b346761043..dc702c0a6034 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -968,8 +968,10 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
 	}
 
 	err = btmtk_usb_id_get(hdev, 0x70010200, &val);
-	if (err || (!val && dev_id != 0x6639))
+	if (err || (!val && dev_id != 0x6639)) {
 		bt_dev_err(hdev, "Can't get device id, subsys reset fail.");
+		return err ? err : -ENODEV;
+	}
 
 	return err;
 }
-- 
2.55.0


^ permalink raw reply related	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-08-15 12:36 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-15 11:56 [PATCH v2 0/2] Bluetooth: btmtk: fix subsystem reset error reporting Ismail Tarim
2026-08-15 11:56 ` [PATCH v2 1/2] Bluetooth: btmtk: Do not report success when subsys reset fails Ismail Tarim
2026-08-15 12:36   ` Bluetooth: btmtk: fix subsystem reset error reporting bluez.test.bot
2026-08-15 11:56 ` [PATCH v2 2/2] Bluetooth: btmtk: Do not discard the subsystem reset timeout Ismail Tarim
  -- strict thread matches above, loose matches on Subject: below --
2026-08-15 11:01 [PATCH 1/2] Bluetooth: btmtk: Fix btmtk_usb_subsys_reset() reporting success on failure Ismail Tarim
2026-08-15 11:35 ` Bluetooth: btmtk: fix subsystem reset error reporting bluez.test.bot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.