[PATCH] Bluetooth: btusb: always reload QCA firmware regardless of chip-reported statu

[PATCH] Bluetooth: btusb: always reload QCA firmware regardless of chip-reported statu

[makro-kernel]

btusb_setup_qca() currently skips rampatch and NVM downloads when the
chip reports QCA_PATCH_UPDATED and QCA_SYSCFG_UPDATED bits set in its
status byte. The intent is to avoid redundant firmware uploads when the
chip is already in the expected state.

However, some QCA chips (notably the WCN785x family, rebadged by Foxconn
as USB 0489:e10a in MSI X870/B850 motherboards) retain firmware state
across reboots in on-die NVM. When a previous OS (e.g. Windows) or an
older driver has loaded a different firmware build, the chip happily
reports PATCH_UPDATED|SYSCFG_UPDATED to QCA_CHECK_STATUS, and btusb
trusts it -- leaving the chip running stale or incompatible firmware.

The user-visible symptom is severe: pairing works, BR/EDR connections
work, AVDTP signaling completes (Discover/GetCaps/SetConfig/Open all
succeed), but the subsequent AVDTP Acquire fails with
org.bluez.Error.Failed and A2DP audio cannot stream. The chip also
emits at startup:

    Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command
                     is advertised, but not supported.

which is a hint that the running firmware is not the rampatch-fixed
version btusb assumes.

Diagnosed on Foxconn 0489:e10a (Qualcomm WCN785x 2.0, ROM 0x00190200)
against a Bose QC Ultra 2 HP headset on an MSI MAG X870E TOMAHAWK WIFI
board: QCA_CHECK_STATUS returned 0xe0 on every probe (after a Windows
install had been wiped), and both firmware loads were skipped, leaving
the chip on Windows-era firmware build 0x8567 instead of Linux's
expected build 0x6254. With the guard removed, btusb downloads the
correct rampatch and NVM, and audio works end-to-end.

The redundant upload on a "truly already-patched" chip costs only a few
hundred milliseconds during enumeration and is the same cost paid by
the equivalent Windows driver path, which is known to always re-flash
firmware on every boot regardless of chip status.

Reported-by: Makro <makro-kernel@proton.me>
Signed-off-by: Makro <makro-kernel@proton.me>
---
 drivers/bluetooth/btusb.c | 45 ++++++++++++++++++++++-----------------
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3afbad667..65c4f0fec 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3646,7 +3646,6 @@ static int btusb_setup_qca(struct hci_dev *hdev)
        const struct qca_device_info *info = NULL;
        struct qca_version ver;
        u32 ver_rom;
-       u8 status;
        int i, err;
 
        err = btusb_qca_send_vendor_req(udev, QCA_GET_TARGET_VERSION, &ver,
@@ -3672,17 +3671,25 @@ static int btusb_setup_qca(struct hci_dev *hdev)
                return -ENODEV;
        }
 
-       err = btusb_qca_send_vendor_req(udev, QCA_CHECK_STATUS, &status,
-                                       sizeof(status));
+       /*
+        * Some QCA chips (notably WCN785x family rebadged by Foxconn as
+        * USB 0489:e10a in MSI X870/B850 motherboards) retain firmware
+        * state across reboots in on-die NVM. After a previous OS or
+        * driver version has loaded firmware, QCA_CHECK_STATUS reports
+        * PATCH_UPDATED|SYSCFG_UPDATED even though the running firmware
+        * may be incompatible with what bluez/btusb expect. Trusting the
+        * status flags then leaves the chip on stale firmware, breaking
+        * AVDTP transport setup (Acquire returns Failed; A2DP audio
+        * cannot stream).
+        *
+        * Always re-apply the rampatch and NVM to guarantee a known-good
+        * firmware state on every probe. The cost is a few hundred
+        * milliseconds of firmware upload during enumeration.
+        */
+       err = btusb_setup_qca_load_rampatch(hdev, &ver, info);
        if (err < 0)
                return err;
 
-       if (!(status & QCA_PATCH_UPDATED)) {
-               err = btusb_setup_qca_load_rampatch(hdev, &ver, info);
-               if (err < 0)
-                       return err;
-       }
-
        err = btusb_qca_send_vendor_req(udev, QCA_GET_TARGET_VERSION, &ver,
                                        sizeof(ver));
        if (err < 0)
@@ -3691,18 +3698,16 @@ static int btusb_setup_qca(struct hci_dev *hdev)
        btdata->qca_dump.fw_version = le32_to_cpu(ver.patch_version);
        btdata->qca_dump.controller_id = le32_to_cpu(ver.rom_version);
 
-       if (!(status & QCA_SYSCFG_UPDATED)) {
-               err = btusb_setup_qca_load_nvm(hdev, &ver, info);
-               if (err < 0)
-                       return err;
+       err = btusb_setup_qca_load_nvm(hdev, &ver, info);
+       if (err < 0)
+               return err;
 
-               /* WCN6855 2.1 and later will reset to apply firmware downloaded here, so
-                * wait ~100ms for reset Done then go ahead, otherwise, it maybe
-                * cause potential enable failure.
-                */
-               if (info->rom_version >= 0x00130201)
-                       msleep(QCA_BT_RESET_WAIT_MS);
-       }
+       /* WCN6855 2.1 and later will reset to apply firmware downloaded here, so
+        * wait ~100ms for reset Done then go ahead, otherwise, it maybe
+        * cause potential enable failure.
+        */
+       if (info->rom_version >= 0x00130201)
+               msleep(QCA_BT_RESET_WAIT_MS);
 
        /* Mark HCI_OP_ENHANCED_SETUP_SYNC_CONN as broken as it doesn't seem to
         * work with the likes of HSP/HFP mSBC.
-- 
2.54.0

RE: Bluetooth: btusb: always reload QCA firmware regardless of chip-reported statu

[bluez.test.bot]

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

This is an automated email and please do not reply to this email.

Dear Submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.

----- Output -----

error: patch failed: drivers/bluetooth/btusb.c:3646
error: drivers/bluetooth/btusb.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch

Please resolve the issue and submit the patches again.


---
Regards,
Linux Bluetooth