[PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[Shuai Zhang]

The Bluetooth host decides whether to download firmware by reading the
controller firmware download completion flag and firmware version
information.

If a USB error occurs during the firmware download process (for example
due to a USB disconnect), the download is aborted immediately. An
incomplete firmware transfer does not cause the controller to set the
download completion flag, but the firmware version information may be
updated at an early stage of the download process.

In this case, after USB reconnection, the host attempts to re-download
the firmware because the download completion flag is not set. However,
since the controller reports the same firmware version as the target
firmware, the download is skipped. This ultimately results in the
firmware not being properly updated on the controller.

This change removes the restriction that skips firmware download when
the versions are equal. It covers scenarios where the USB connection
can be disconnected at any time and ensures that firmware download can
be retriggered after USB reconnection, allowing the Bluetooth firmware
to be correctly and completely updated.

Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
---
Changes v2:
- Update code comments and commit message to reflect the correct logic.
- Align the commit title with upstream conventions.
- Link v1
  https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
---
 drivers/bluetooth/btusb.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 572091e60..70abbabea 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
 		    "firmware rome 0x%x build 0x%x",
 		    rver_rom, rver_patch, ver_rom, ver_patch);
 
-	if (rver_rom != ver_rom || rver_patch <= ver_patch) {
+	/* Allow rampatch when the patch version equals the firmware version.
+	 * A firmware download may be aborted by a transient USB error (e.g.
+	 * disconnect) after the controller updates version info but before
+	 * completion.
+	 * Allowing equal versions enables re-flashing during recovery.
+	 */
+	if (rver_rom != ver_rom || rver_patch < ver_patch) {
 		bt_dev_err(hdev, "rampatch file version did not match with firmware");
 		err = -EINVAL;
 		goto done;
-- 
2.34.1

RE: [v2] Bluetooth: btusb: Allow firmware re-download when version matches

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1527 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=1087449

---Test result---

Test Summary:
CheckPatch                    PASS      0.59 seconds
GitLint                       FAIL      0.25 seconds
SubjectPrefix                 PASS      0.08 seconds
BuildKernel                   PASS      24.84 seconds
CheckAllWarning               PASS      28.00 seconds
CheckSparse                   PASS      26.10 seconds
BuildKernel32                 PASS      24.71 seconds
TestRunnerSetup               PASS      524.21 seconds
IncrementalBuild              PASS      23.70 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v2] Bluetooth: btusb: Allow firmware re-download when version matches

WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
31: B1 Line exceeds max length (84>80): "  https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/"


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

---
Regards,
Linux Bluetooth

Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[Luiz Augusto von Dentz]

Hi Shuai,

On Wed, Apr 29, 2026 at 8:12 AM Shuai Zhang
<shuai.zhang@oss.qualcomm.com> wrote:
>
> The Bluetooth host decides whether to download firmware by reading the
> controller firmware download completion flag and firmware version
> information.
>
> If a USB error occurs during the firmware download process (for example
> due to a USB disconnect), the download is aborted immediately. An
> incomplete firmware transfer does not cause the controller to set the
> download completion flag, but the firmware version information may be
> updated at an early stage of the download process.

Hold on, if the download has been aborted then the version should be
reverted, or rather just update once the firmware loading is complete,
so this indicates there is a bug somewhere that needs fixing, not
worked around.

> In this case, after USB reconnection, the host attempts to re-download
> the firmware because the download completion flag is not set. However,
> since the controller reports the same firmware version as the target
> firmware, the download is skipped. This ultimately results in the
> firmware not being properly updated on the controller.
>
> This change removes the restriction that skips firmware download when
> the versions are equal. It covers scenarios where the USB connection
> can be disconnected at any time and ensures that firmware download can
> be retriggered after USB reconnection, allowing the Bluetooth firmware
> to be correctly and completely updated.
>
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> ---
> Changes v2:
> - Update code comments and commit message to reflect the correct logic.
> - Align the commit title with upstream conventions.
> - Link v1
>   https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
> ---
>  drivers/bluetooth/btusb.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 572091e60..70abbabea 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
>                     "firmware rome 0x%x build 0x%x",
>                     rver_rom, rver_patch, ver_rom, ver_patch);
>
> -       if (rver_rom != ver_rom || rver_patch <= ver_patch) {
> +       /* Allow rampatch when the patch version equals the firmware version.
> +        * A firmware download may be aborted by a transient USB error (e.g.
> +        * disconnect) after the controller updates version info but before
> +        * completion.
> +        * Allowing equal versions enables re-flashing during recovery.
> +        */
> +       if (rver_rom != ver_rom || rver_patch < ver_patch) {

As I said above, this sounds more like a workaround. That said, I
wonder why it would print an error if the version matches, it sounds
to be that if the version matches it should just skip and consider it
has been loaded already in case the actual problem is fixed by setting
the new version only when loading has been completed.

>                 bt_dev_err(hdev, "rampatch file version did not match with firmware");
>                 err = -EINVAL;
>                 goto done;
> --
> 2.34.1
>


-- 
Luiz Augusto von Dentz

Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[Luiz Augusto von Dentz]

Hi Shuai,

On Wed, Apr 29, 2026 at 11:17 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Shuai,
>
> On Wed, Apr 29, 2026 at 8:12 AM Shuai Zhang
> <shuai.zhang@oss.qualcomm.com> wrote:
> >
> > The Bluetooth host decides whether to download firmware by reading the
> > controller firmware download completion flag and firmware version
> > information.
> >
> > If a USB error occurs during the firmware download process (for example
> > due to a USB disconnect), the download is aborted immediately. An
> > incomplete firmware transfer does not cause the controller to set the
> > download completion flag, but the firmware version information may be
> > updated at an early stage of the download process.
>
> Hold on, if the download has been aborted then the version should be
> reverted, or rather just update once the firmware loading is complete,
> so this indicates there is a bug somewhere that needs fixing, not
> worked around.
>
> > In this case, after USB reconnection, the host attempts to re-download
> > the firmware because the download completion flag is not set. However,
> > since the controller reports the same firmware version as the target
> > firmware, the download is skipped. This ultimately results in the
> > firmware not being properly updated on the controller.
> >
> > This change removes the restriction that skips firmware download when
> > the versions are equal. It covers scenarios where the USB connection
> > can be disconnected at any time and ensures that firmware download can
> > be retriggered after USB reconnection, allowing the Bluetooth firmware
> > to be correctly and completely updated.
> >
> > Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> > ---
> > Changes v2:
> > - Update code comments and commit message to reflect the correct logic.
> > - Align the commit title with upstream conventions.
> > - Link v1
> >   https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
> > ---
> >  drivers/bluetooth/btusb.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 572091e60..70abbabea 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
> >                     "firmware rome 0x%x build 0x%x",
> >                     rver_rom, rver_patch, ver_rom, ver_patch);
> >
> > -       if (rver_rom != ver_rom || rver_patch <= ver_patch) {
> > +       /* Allow rampatch when the patch version equals the firmware version.
> > +        * A firmware download may be aborted by a transient USB error (e.g.
> > +        * disconnect) after the controller updates version info but before
> > +        * completion.
> > +        * Allowing equal versions enables re-flashing during recovery.
> > +        */
> > +       if (rver_rom != ver_rom || rver_patch < ver_patch) {
>
> As I said above, this sounds more like a workaround. That said, I
> wonder why it would print an error if the version matches, it sounds
> to be that if the version matches it should just skip and consider it
> has been loaded already in case the actual problem is fixed by setting
> the new version only when loading has been completed.

Btw, the following also seem valid although not introduced by this change:

https://sashiko.dev/#/patchset/20260429121207.1306526-1-shuai.zhang%40oss.qualcomm.com

> >                 bt_dev_err(hdev, "rampatch file version did not match with firmware");
> >                 err = -EINVAL;
> >                 goto done;
> > --
> > 2.34.1
> >
>
>
> --
> Luiz Augusto von Dentz



-- 
Luiz Augusto von Dentz

Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[Shuai Zhang]

Hi  Luiz

On 4/30/2026 12:14 AM, Luiz Augusto von Dentz wrote:
> Hi Shuai,
>
> On Wed, Apr 29, 2026 at 11:17 AM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Shuai,
>>
>> On Wed, Apr 29, 2026 at 8:12 AM Shuai Zhang
>> <shuai.zhang@oss.qualcomm.com> wrote:
>>> The Bluetooth host decides whether to download firmware by reading the
>>> controller firmware download completion flag and firmware version
>>> information.
>>>
>>> If a USB error occurs during the firmware download process (for example
>>> due to a USB disconnect), the download is aborted immediately. An
>>> incomplete firmware transfer does not cause the controller to set the
>>> download completion flag, but the firmware version information may be
>>> updated at an early stage of the download process.
>> Hold on, if the download has been aborted then the version should be
>> reverted, or rather just update once the firmware loading is complete,
>> so this indicates there is a bug somewhere that needs fixing, not
>> worked around.
>>
>>> In this case, after USB reconnection, the host attempts to re-download
>>> the firmware because the download completion flag is not set. However,
>>> since the controller reports the same firmware version as the target
>>> firmware, the download is skipped. This ultimately results in the
>>> firmware not being properly updated on the controller.
>>>
>>> This change removes the restriction that skips firmware download when
>>> the versions are equal. It covers scenarios where the USB connection
>>> can be disconnected at any time and ensures that firmware download can
>>> be retriggered after USB reconnection, allowing the Bluetooth firmware
>>> to be correctly and completely updated.
>>>
>>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>>> ---
>>> Changes v2:
>>> - Update code comments and commit message to reflect the correct logic.
>>> - Align the commit title with upstream conventions.
>>> - Link v1
>>>    https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
>>> ---
>>>   drivers/bluetooth/btusb.c | 8 +++++++-
>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>>> index 572091e60..70abbabea 100644
>>> --- a/drivers/bluetooth/btusb.c
>>> +++ b/drivers/bluetooth/btusb.c
>>> @@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
>>>                      "firmware rome 0x%x build 0x%x",
>>>                      rver_rom, rver_patch, ver_rom, ver_patch);
>>>
>>> -       if (rver_rom != ver_rom || rver_patch <= ver_patch) {
>>> +       /* Allow rampatch when the patch version equals the firmware version.
>>> +        * A firmware download may be aborted by a transient USB error (e.g.
>>> +        * disconnect) after the controller updates version info but before
>>> +        * completion.
>>> +        * Allowing equal versions enables re-flashing during recovery.
>>> +        */
>>> +       if (rver_rom != ver_rom || rver_patch < ver_patch) {
>> As I said above, this sounds more like a workaround. That said, I
>> wonder why it would print an error if the version matches, it sounds
>> to be that if the version matches it should just skip and consider it
>> has been loaded already in case the actual problem is fixed by setting
>> the new version only when loading has been completed.
> Btw, the following also seem valid although not introduced by this change:
>
> https://sashiko.dev/#/patchset/20260429121207.1306526-1-shuai.zhang%40oss.qualcomm.com


I will check this and submit a new patch if it is issue.


>
>>>                  bt_dev_err(hdev, "rampatch file version did not match with firmware");
>>>                  err = -EINVAL;
>>>                  goto done;
>>> --
>>> 2.34.1
>>>
>>
>> --
>> Luiz Augusto von Dentz

Thanks,

Shuai

>
>

Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[Shuai Zhang]

Hi Luiz

On 4/29/2026 11:17 PM, Luiz Augusto von Dentz wrote:
> Hi Shuai,
>
> On Wed, Apr 29, 2026 at 8:12 AM Shuai Zhang
> <shuai.zhang@oss.qualcomm.com> wrote:
>> The Bluetooth host decides whether to download firmware by reading the
>> controller firmware download completion flag and firmware version
>> information.
>>
>> If a USB error occurs during the firmware download process (for example
>> due to a USB disconnect), the download is aborted immediately. An
>> incomplete firmware transfer does not cause the controller to set the
>> download completion flag, but the firmware version information may be
>> updated at an early stage of the download process.
> Hold on, if the download has been aborted then the version should be
> reverted, or rather just update once the firmware loading is complete,
> so this indicates there is a bug somewhere that needs fixing, not
> worked around.
>
>> In this case, after USB reconnection, the host attempts to re-download
>> the firmware because the download completion flag is not set. However,
>> since the controller reports the same firmware version as the target
>> firmware, the download is skipped. This ultimately results in the
>> firmware not being properly updated on the controller.
>>
>> This change removes the restriction that skips firmware download when
>> the versions are equal. It covers scenarios where the USB connection
>> can be disconnected at any time and ensures that firmware download can
>> be retriggered after USB reconnection, allowing the Bluetooth firmware
>> to be correctly and completely updated.
>>
>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>> ---
>> Changes v2:
>> - Update code comments and commit message to reflect the correct logic.
>> - Align the commit title with upstream conventions.
>> - Link v1
>>    https://lore.kernel.org/all/20260108074353.1027877-1-shuai.zhang@oss.qualcomm.com/
>> ---
>>   drivers/bluetooth/btusb.c | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>> index 572091e60..70abbabea 100644
>> --- a/drivers/bluetooth/btusb.c
>> +++ b/drivers/bluetooth/btusb.c
>> @@ -3550,7 +3550,13 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev,
>>                      "firmware rome 0x%x build 0x%x",
>>                      rver_rom, rver_patch, ver_rom, ver_patch);
>>
>> -       if (rver_rom != ver_rom || rver_patch <= ver_patch) {
>> +       /* Allow rampatch when the patch version equals the firmware version.
>> +        * A firmware download may be aborted by a transient USB error (e.g.
>> +        * disconnect) after the controller updates version info but before
>> +        * completion.
>> +        * Allowing equal versions enables re-flashing during recovery.
>> +        */
>> +       if (rver_rom != ver_rom || rver_patch < ver_patch) {
> As I said above, this sounds more like a workaround. That said, I
> wonder why it would print an error if the version matches, it sounds
> to be that if the version matches it should just skip and consider it
> has been loaded already in case the actual problem is fixed by setting
> the new version only when loading has been completed.


Correct, we cannot reliably detect if the download was aborted mid-flight,
so the version information may not always be accurate.

However, we only force a reload in cases where the firmware integrity
cannot be guaranteed. If the firmware download has completed successfully,
even if a USB disconnect happens afterward, we will not reload it, as the
controller already contains a complete and valid firmware.


>>                  bt_dev_err(hdev, "rampatch file version did not match with firmware");
>>                  err = -EINVAL;
>>                  goto done;
>> --
>> 2.34.1
>>
>

Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches

[makro-kernel]

Hi Shuai, Luiz,

I sent a patch earlier today touching the same function for a related
but distinct failure mode in the same family of chips, and only just
saw this thread.

  https://lore.kernel.org/linux-bluetooth/aD_Lix2EVXOHmbZ4L1CunlWiLqfiKlU_1_FcVh4CBuIgud4kmE_544xjW2zFKsmh4pNAo9yIQ7q8_GZ4YcmgAXPp8LgW9rfWKqnu06WSjgk=@proton.me/T/#u

In my case the *outer* check fails first: on Foxconn USB 0489:e10a
(Qualcomm WCN6855/WCN785x, ROM 0x00190200) the chip reports
QCA_CHECK_STATUS = 0xe0 (PATCH_UPDATED | SYSCFG_UPDATED) on every
probe, so btusb_setup_qca() never reaches load_rampatch() or
load_nvm(), returns 0, and the controller runs unpatched firmware.

AVDTP setup later fails on Acquire and A2DP audio cannot stream. The
PATCH_UPDATED bit appears to persist across cold boots somewhere on
chip -- originally set by Windows on dual-boot-then-Linux systems
we've seen, but the bit sticks even after a successful Linux firmware
upload, so subsequent boots also see 0xe0 and skip.

The rampatch itself also persists on this silicon at least across
suspend/hibernate resume cycles and driver reload (whether it
survives a true cold boot I haven't isolated). Either way, once an
upload has succeeded the chip reports patch_version equal to the
file's version on subsequent probes, which is exactly the condition
your patch addresses. With my outer bypass in place but without your
inner change, the second and subsequent probes hit the existing
`rver_patch <= ver_patch` check, return -EINVAL, and controller
setup aborts entirely:

  Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00190200.bin
  Bluetooth: hci0: QCA: patch rome 0x190200 build 0x8567, firmware rome 0x190200 build 0x8567
  Bluetooth: hci0: rampatch file version did not match with firmware
  (btusb_setup_qca returns -EINVAL, hci0 never finishes registering)

So your fix is doing the right thing here, and on this hardware both
sides are needed together for the chip to come up cleanly across
reload / reboot cycles.

In my local tree I skip reuploading on equal versions rather than 
re-uploading on every probe:

  if (rver_rom != ver_rom) {
          bt_dev_err(hdev, "rampatch file ROM did not match controller");
          err = -EINVAL;
          goto done;
  }

  if (rver_patch <= ver_patch) {
          bt_dev_info(hdev, "QCA: rampatch already current, skipping download");
          err = 0;
          goto done;
  }

  err = btusb_setup_qca_download_fw(hdev, fw, info->rampatch_hdr);

Best,
Makro