[PATCH v2 1/2] Bluetooth: btintel: Fix spurious error on FW download error recovery

[PATCH v2 1/2] Bluetooth: btintel: Fix spurious error on FW download error recovery

[Ameen Al-Asady]

When the firmware download errors out because the controller is
running an operational image whose version does not match the
firmware file on disk, btintel_reset_to_bootloader() sends the Intel
Reset vendor command to force the controller back into bootloader
mode and retry the download. This is the normal upgrade path after a
linux-firmware update followed by a warm reboot, since the
operational image survives in controller RAM. In the log below the
controller is still running build 81755 (2024.33) while
intel/ibt-0041-0041.sfi on disk contains build 82122 (2026.5).

The controller acts on Intel Reset by resetting and re-enumerating
on the bus. This can happen before the command complete event is
delivered, in which case __hci_cmd_sync() returns -ENODEV and the
driver logs a misleading error even though recovery is working:

  Bluetooth: hci0: Firmware timestamp 2024.33 buildtype 1 build 81755
  Bluetooth: hci0: Found device firmware: intel/ibt-0041-0041.sfi
  usb 1-6: USB disconnect, device number 4
  Bluetooth: hci0: FW download error recovery failed (-19)
  usb 1-6: new full-speed USB device number 5 using xhci_hcd
  ...
  Bluetooth: hci0: Firmware loaded in 2827613 usecs
  Bluetooth: hci0: Firmware timestamp 2026.5 buildtype 1 build 82122

Treat -ENODEV as the expected outcome of the reset and keep the
error message for genuine failures.

Tested on an Intel AX210 (USB 8087:0032) on a 7.1.3 kernel by
rebinding btusb with a non-matching firmware file on disk, in both
the downgrade and upgrade direction. Both runs took the -ENODEV
path, logged the info message instead of the error and completed
the download after re-enumeration.

Signed-off-by: Ameen Al-Asady <ameenaladdin@gmail.com>
---
v2: reword commit message, add firmware versions and tested system
    (Paul Menzel)

 drivers/bluetooth/btintel.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
index 5e9cac090..472542bff 100644
--- a/drivers/bluetooth/btintel.c
+++ b/drivers/bluetooth/btintel.c
@@ -1363,12 +1363,22 @@ static void btintel_reset_to_bootloader(struct hci_dev *hdev)
 	skb = __hci_cmd_sync(hdev, BTINTEL_HCI_OP_RESET, sizeof(params),
 			     &params, HCI_INIT_TIMEOUT);
 	if (IS_ERR(skb)) {
-		bt_dev_err(hdev, "FW download error recovery failed (%ld)",
-			   PTR_ERR(skb));
-		return;
+		/* The controller acts on Intel Reset by resetting and
+		 * re-enumerating on the bus, which can happen before the
+		 * command complete event is delivered. The resulting
+		 * -ENODEV means the reset took effect, not that recovery
+		 * failed.
+		 */
+		if (PTR_ERR(skb) != -ENODEV) {
+			bt_dev_err(hdev,
+				   "FW download error recovery failed (%ld)",
+				   PTR_ERR(skb));
+			return;
+		}
+	} else {
+		kfree_skb(skb);
 	}
 	bt_dev_info(hdev, "Intel reset sent to retry FW download");
-	kfree_skb(skb);
 
 	/* Current Intel BT controllers(ThP/JfP) hold the USB reset
 	 * lines for 2ms when it receives Intel Reset in bootloader mode.

base-commit: eab19cb7618e5c50fd1f8c1efdc4e66e16575975
-- 
2.55.0

[PATCH v2 2/2] Bluetooth: hci_sync: Skip MSFT/AOSP init when controller init failed

[Ameen Al-Asady]

hci_dev_init_sync() calls msft_do_open() and aosp_do_open()
unconditionally, even when setup or the HCI init sequence has already
failed. Both send vendor commands with __hci_cmd_sync(), so on a dead
or uninitialized controller each of them blocks the power-on sequence
for a full HCI_CMD_TIMEOUT and logs a spurious error.

This is easy to trigger with an Intel USB controller that needs a
firmware upgrade: btintel resets the controller to bootloader mode,
the device drops off the bus and hdev->setup() fails with -EINVAL,
after which msft_do_open() still spends two more seconds waiting for
a response that cannot arrive:

  usb 1-6: USB disconnect, device number 4
  Bluetooth: hci0: FW download error recovery failed (-19)
  Bluetooth: hci0: Failed to read MSFT supported features (-110)
  usb 1-6: new full-speed USB device number 5 using xhci_hcd

Only initialize the MSFT and AOSP extensions when the controller
initialized successfully.

Signed-off-by: Ameen Al-Asady <ameenaladdin@gmail.com>
---
v2: no changes

 net/bluetooth/hci_sync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index b4ca34abe..38158835c 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -5173,7 +5173,7 @@ static int hci_dev_init_sync(struct hci_dev *hdev)
 	    hci_dev_test_flag(hdev, HCI_VENDOR_DIAG) && hdev->set_diag)
 		ret = hdev->set_diag(hdev, true);
 
-	if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
+	if (!ret && !hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
 		msft_do_open(hdev);
 		aosp_do_open(hdev);
 	}
-- 
2.55.0

RE: [v2,1/2] Bluetooth: btintel: Fix spurious error on FW download error recovery

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2389 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1127044

---Test result---

Test Summary:
CheckPatch                    PASS      1.98 seconds
VerifyFixes                   PASS      0.14 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       PASS      0.66 seconds
SubjectPrefix                 PASS      0.26 seconds
BuildKernel                   PASS      27.14 seconds
CheckAllWarning               PASS      29.69 seconds
CheckSparse                   PASS      28.86 seconds
BuildKernel32                 PASS      26.47 seconds
CheckKernelLLVM               SKIP      0.00 seconds
TestRunnerSetup               PASS      505.27 seconds
TestRunner_l2cap-tester       PASS      59.79 seconds
TestRunner_iso-tester         PASS      79.40 seconds
TestRunner_bnep-tester        PASS      19.40 seconds
TestRunner_mgmt-tester        FAIL      215.28 seconds
TestRunner_rfcomm-tester      PASS      26.08 seconds
TestRunner_sco-tester         PASS      31.19 seconds
TestRunner_ioctl-tester       PASS      26.21 seconds
TestRunner_mesh-tester        FAIL      25.93 seconds
TestRunner_smp-tester         PASS      23.56 seconds
TestRunner_userchan-tester    PASS      20.31 seconds
TestRunner_6lowpan-tester     PASS      23.19 seconds
IncrementalBuild              PASS      29.35 seconds

Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.245 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.180 seconds
Mesh - Send cancel - 2                               Timed out    1.983 seconds


https://github.com/bluez/bluetooth-next/pull/435

---
Regards,
Linux Bluetooth