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

[Shuai Zhang <shuai.zhang@oss.qualcomm.com>]

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

>
>