Bluetooth: btintel: Fix spurious error on FW download error recovery
Subsystems (2)
PATCH v2 1/2 Bluetooth: btintel: Fix spurious error on FW download error recovery
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.
---
v2: reword commit message, add firmware versions and tested system
(Paul Menzel)
drivers/bluetooth/btintel.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-)
drivers/bluetooth/btintel.c +14 -4
@@ -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), ¶ms,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
Signature · 1 line
2.55.0
PATCH v2 2/2 Bluetooth: hci_sync: Skip MSFT/AOSP init when controller init failed
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.
---
v2: no changes
net/bluetooth/hci_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/bluetooth/hci_sync.c +1 -1
@@ -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); }
Signature · 1 line
2.55.0
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