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

From: Luiz Augusto von Dentz

Date: Wed May 20 2026 - 08:52:24 EST


Hi Shuai,

On Wed, May 20, 2026 at 2:26 AM Shuai Zhang
<shuai.zhang@xxxxxxxxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx>
> >> ---
> >> 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@xxxxxxxxxxxxxxxx/
> >> ---
> >> 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
>
> Just checking if there are any updates on this

I had the impression there would be more changes needed, if this not
the case than let me know, also perhaps we should consider adding a
Fixes tag since this might help users experiencing problem if they are
dual booting or somehow got the wrong firmware to be loaded.

>
> Thanks,
>
> Shuai
>
> >



--
Luiz Augusto von Dentz