* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
2026-04-29 15:17 ` [PATCH v2] " Luiz Augusto von Dentz
@ 2026-04-29 16:14 ` Luiz Augusto von Dentz
2026-05-13 7:52 ` Shuai Zhang
2026-05-13 7:50 ` Shuai Zhang
2026-05-20 6:26 ` Shuai Zhang
2 siblings, 1 reply; 10+ messages in thread
From: Luiz Augusto von Dentz @ 2026-04-29 16:14 UTC (permalink / raw)
To: Shuai Zhang
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
2026-04-29 16:14 ` Luiz Augusto von Dentz
@ 2026-05-13 7:52 ` Shuai Zhang
0 siblings, 0 replies; 10+ messages in thread
From: Shuai Zhang @ 2026-05-13 7:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
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
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
2026-04-29 15:17 ` [PATCH v2] " Luiz Augusto von Dentz
2026-04-29 16:14 ` Luiz Augusto von Dentz
@ 2026-05-13 7:50 ` Shuai Zhang
2026-05-20 6:26 ` Shuai Zhang
2 siblings, 0 replies; 10+ messages in thread
From: Shuai Zhang @ 2026-05-13 7:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
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
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
2026-04-29 15:17 ` [PATCH v2] " Luiz Augusto von Dentz
2026-04-29 16:14 ` Luiz Augusto von Dentz
2026-05-13 7:50 ` Shuai Zhang
@ 2026-05-20 6:26 ` Shuai Zhang
2026-05-20 12:45 ` Luiz Augusto von Dentz
2 siblings, 1 reply; 10+ messages in thread
From: Shuai Zhang @ 2026-05-20 6:26 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
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.
>
>> 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
Thanks,
Shuai
>
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
2026-05-20 6:26 ` Shuai Zhang
@ 2026-05-20 12:45 ` Luiz Augusto von Dentz
2026-05-21 5:35 ` Shuai Zhang
0 siblings, 1 reply; 10+ messages in thread
From: Luiz Augusto von Dentz @ 2026-05-20 12:45 UTC (permalink / raw)
To: Shuai Zhang
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
Hi Shuai,
On Wed, May 20, 2026 at 2:26 AM Shuai Zhang
<shuai.zhang@oss.qualcomm.com> 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@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
>
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v2] Bluetooth: btusb: Allow firmware re-download when version matches
2026-05-20 12:45 ` Luiz Augusto von Dentz
@ 2026-05-21 5:35 ` Shuai Zhang
0 siblings, 0 replies; 10+ messages in thread
From: Shuai Zhang @ 2026-05-21 5:35 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, linux-bluetooth, linux-kernel, linux-arm-msm,
cheng.jiang, quic_chezhou, wei.deng, jinwang.li, mengshi.wu
Hi Luiz
On 5/20/2026 8:45 PM, Luiz Augusto von Dentz wrote:
> Hi Shuai,
>
> On Wed, May 20, 2026 at 2:26 AM Shuai Zhang
> <shuai.zhang@oss.qualcomm.com> 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@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.
From my understanding, the current changes should already cover this case,
so no further modifications seem necessary. Please let me know if you
see it differently.
I will add a Fixes tag in the next revision.
>>>> 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
>>
Thanks,
Shuai
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread