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

[Ameen Al-Asady <ameenaladdin@gmail.com>]

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