[PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Shuai Zhang]

When bt_en is pulled high by hardware, the host does not re-download
the firmware after SSR. The controller loads the rampatch and NVM
internally.

On HMT chip, due to the large firmware file size, the
loading process takes approximately 70ms. The previous 50ms delay is
too short, causing the controller to not respond to the reset command
sent by the host, which leads to BT initialization failure.

Increase the delay to 100ms to ensure the controller has finished
loading the firmware before the host sends commands.

Steps to reproduce:
1. Trigger SSR and wait for SSR to complete:
   hcitool cmd 0x3f 0c 26
2. Run "bluetoothctl power on" and observe that BT fails to start.

Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
Cc: stable@vger.kernel.org
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
---
 drivers/bluetooth/hci_qca.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index ed280399b..184f52f9c 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
 		mod_timer(&qca->tx_idle_timer, jiffies +
 				  msecs_to_jiffies(qca->tx_idle_delay));
 
-		/* Controller reset completion time is 50ms */
-		msleep(50);
+		/* Wait for the controller to load the rampatch and NVM.*/
+		msleep(100);
 
 		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
 		clear_bit(QCA_IBS_DISABLED, &qca->flags);
-- 
2.34.1

RE: [v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[bluez.test.bot]

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

---Test result---

Test Summary:
CheckPatch                    PASS      0.72 seconds
VerifyFixes                   PASS      0.13 seconds
VerifySignedoff               PASS      0.13 seconds
GitLint                       PASS      0.32 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      26.24 seconds
CheckAllWarning               PASS      31.73 seconds
CheckSparse                   PASS      28.54 seconds
BuildKernel32                 PASS      26.68 seconds
TestRunnerSetup               PASS      535.95 seconds
IncrementalBuild              PASS      24.16 seconds



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

---
Regards,
Linux Bluetooth

Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Dmitry Baryshkov]

On Fri, May 22, 2026 at 07:08:38PM +0800, Shuai Zhang wrote:
> When bt_en is pulled high by hardware, the host does not re-download
> the firmware after SSR. The controller loads the rampatch and NVM
> internally.
> 
> On HMT chip, due to the large firmware file size, the
> loading process takes approximately 70ms. The previous 50ms delay is
> too short, causing the controller to not respond to the reset command
> sent by the host, which leads to BT initialization failure.
> 
> Increase the delay to 100ms to ensure the controller has finished
> loading the firmware before the host sends commands.
> 
> Steps to reproduce:
> 1. Trigger SSR and wait for SSR to complete:
>    hcitool cmd 0x3f 0c 26
> 2. Run "bluetoothctl power on" and observe that BT fails to start.
> 
> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> ---
>  drivers/bluetooth/hci_qca.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Paul Menzel]

Dear Shuai,


Thank you for your patch. Please mention the delay in the summary/title. 
Maybe:

Use 100 ms SSR delay for rampatch and NVM loading

Am 22.05.26 um 13:08 schrieb Shuai Zhang:
> When bt_en is pulled high by hardware, the host does not re-download
> the firmware after SSR. The controller loads the rampatch and NVM
> internally.
> 
> On HMT chip, due to the large firmware file size, the

Please document the size (> X MB)

> loading process takes approximately 70ms. The previous 50ms delay is
> too short, causing the controller to not respond to the reset command
> sent by the host, which leads to BT initialization failure.

Maybe paste the log?

> Increase the delay to 100ms to ensure the controller has finished
> loading the firmware before the host sends commands.

Why can’t it be increased to 1 s?

> Steps to reproduce:
> 1. Trigger SSR and wait for SSR to complete:
>     hcitool cmd 0x3f 0c 26
> 2. Run "bluetoothctl power on" and observe that BT fails to start.
> 
> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> ---
>   drivers/bluetooth/hci_qca.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index ed280399b..184f52f9c 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
>   		mod_timer(&qca->tx_idle_timer, jiffies +
>   				  msecs_to_jiffies(qca->tx_idle_delay));
>   
> -		/* Controller reset completion time is 50ms */
> -		msleep(50);
> +		/* Wait for the controller to load the rampatch and NVM.*/

Missing space at the end.

> +		msleep(100);
>   
>   		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>   		clear_bit(QCA_IBS_DISABLED, &qca->flags);

Is the time it took to load the rampatch and NVM visible in the logs?


Kind regards,

Paul

Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Luiz Augusto von Dentz]

Hi Paul,

On Fri, May 22, 2026 at 10:50 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> Dear Shuai,
>
>
> Thank you for your patch. Please mention the delay in the summary/title.
> Maybe:
>
> Use 100 ms SSR delay for rampatch and NVM loading
>
> Am 22.05.26 um 13:08 schrieb Shuai Zhang:
> > When bt_en is pulled high by hardware, the host does not re-download
> > the firmware after SSR. The controller loads the rampatch and NVM
> > internally.
> >
> > On HMT chip, due to the large firmware file size, the
>
> Please document the size (> X MB)
>
> > loading process takes approximately 70ms. The previous 50ms delay is
> > too short, causing the controller to not respond to the reset command
> > sent by the host, which leads to BT initialization failure.
>
> Maybe paste the log?
>
> > Increase the delay to 100ms to ensure the controller has finished
> > loading the firmware before the host sends commands.
>
> Why can’t it be increased to 1 s?

Why would increasing it to 1s be a good idea? Actually a _proper_
driver should be able to detect when loading has finished, not just
use an arbitrary timer and hope that works and the controller is
responsive afterward.

> > Steps to reproduce:
> > 1. Trigger SSR and wait for SSR to complete:
> >     hcitool cmd 0x3f 0c 26
> > 2. Run "bluetoothctl power on" and observe that BT fails to start.
> >
> > Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> > ---
> >   drivers/bluetooth/hci_qca.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index ed280399b..184f52f9c 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
> >               mod_timer(&qca->tx_idle_timer, jiffies +
> >                                 msecs_to_jiffies(qca->tx_idle_delay));
> >
> > -             /* Controller reset completion time is 50ms */
> > -             msleep(50);
> > +             /* Wait for the controller to load the rampatch and NVM.*/
>
> Missing space at the end.
>
> > +             msleep(100);
> >
> >               clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
> >               clear_bit(QCA_IBS_DISABLED, &qca->flags);
>
> Is the time it took to load the rampatch and NVM visible in the logs?
>
>
> Kind regards,
>
> Paul



-- 
Luiz Augusto von Dentz

Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Paul Menzel]

Dear Luiz,


Thank you for your reply.

Am 22.05.26 um 18:22 schrieb Luiz Augusto von Dentz:

> On Fri, May 22, 2026 at 10:50 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:

>> Thank you for your patch. Please mention the delay in the summary/title.
>> Maybe:
>>
>> Use 100 ms SSR delay for rampatch and NVM loading
>>
>> Am 22.05.26 um 13:08 schrieb Shuai Zhang:
>>> When bt_en is pulled high by hardware, the host does not re-download
>>> the firmware after SSR. The controller loads the rampatch and NVM
>>> internally.
>>>
>>> On HMT chip, due to the large firmware file size, the
>>
>> Please document the size (> X MB)
>>
>>> loading process takes approximately 70ms. The previous 50ms delay is
>>> too short, causing the controller to not respond to the reset command
>>> sent by the host, which leads to BT initialization failure.
>>
>> Maybe paste the log?
>>
>>> Increase the delay to 100ms to ensure the controller has finished
>>> loading the firmware before the host sends commands.
>>
>> Why can’t it be increased to 1 s?
> 
> Why would increasing it to 1s be a good idea? Actually a _proper_
> driver should be able to detect when loading has finished, not just
> use an arbitrary timer and hope that works and the controller is
> responsive afterward.

Indeed it’s not a fail safe in this case, and that’s what my comment was 
about, that it should be explained why 100 ms is chosen, and not a 
flexible way implemented. Sorry for not being clear.

>>> Steps to reproduce:
>>> 1. Trigger SSR and wait for SSR to complete:
>>>      hcitool cmd 0x3f 0c 26
>>> 2. Run "bluetoothctl power on" and observe that BT fails to start.
>>>
>>> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>>> ---
>>>    drivers/bluetooth/hci_qca.c | 4 ++--
>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>>> index ed280399b..184f52f9c 100644
>>> --- a/drivers/bluetooth/hci_qca.c
>>> +++ b/drivers/bluetooth/hci_qca.c
>>> @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
>>>                mod_timer(&qca->tx_idle_timer, jiffies +
>>>                                  msecs_to_jiffies(qca->tx_idle_delay));
>>>
>>> -             /* Controller reset completion time is 50ms */
>>> -             msleep(50);
>>> +             /* Wait for the controller to load the rampatch and NVM.*/
>>
>> Missing space at the end.
>>
>>> +             msleep(100);
>>>
>>>                clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>>>                clear_bit(QCA_IBS_DISABLED, &qca->flags);
>>
>> Is the time it took to load the rampatch and NVM visible in the logs?


Kind regards,

Paul

Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Shuai Zhang]

Hi Paul, Luiz

On 5/23/2026 4:42 AM, Paul Menzel wrote:
> Dear Luiz,
>
>
> Thank you for your reply.
>
> Am 22.05.26 um 18:22 schrieb Luiz Augusto von Dentz:
>
>> On Fri, May 22, 2026 at 10:50 AM Paul Menzel <pmenzel@molgen.mpg.de> 
>> wrote:
>
>>> Thank you for your patch. Please mention the delay in the 
>>> summary/title.
>>> Maybe:
>>>
>>> Use 100 ms SSR delay for rampatch and NVM loading
>>>
>>> Am 22.05.26 um 13:08 schrieb Shuai Zhang:
>>>> When bt_en is pulled high by hardware, the host does not re-download
>>>> the firmware after SSR. The controller loads the rampatch and NVM
>>>> internally.
>>>>
>>>> On HMT chip, due to the large firmware file size, the
>>>
>>> Please document the size (> X MB)
>>>
>>>> loading process takes approximately 70ms. The previous 50ms delay is
>>>> too short, causing the controller to not respond to the reset command
>>>> sent by the host, which leads to BT initialization failure.
>>>
>>> Maybe paste the log?
>>>
>>>> Increase the delay to 100ms to ensure the controller has finished
>>>> loading the firmware before the host sends commands.
>>>
>>> Why can’t it be increased to 1 s?
>>
>> Why would increasing it to 1s be a good idea? Actually a _proper_
>> driver should be able to detect when loading has finished, not just
>> use an arbitrary timer and hope that works and the controller is
>> responsive afterward.
>
> Indeed it’s not a fail safe in this case, and that’s what my comment 
> was about, that it should be explained why 100 ms is chosen, and not a 
> flexible way implemented. Sorry for not being clear.


The 100 ms value is based on actual measurement data from the controller 
team. In HMT2.1 ROM,
the BT boot time (warm reset, which is the SSR recovery path) was 
observed to approach 50+ ms.

The previous 50 ms delay therefore provides no margin, causing 
intermittent initialization failures.

100 ms was chosen as it gives approximately 2x margin over the observed 
worst-case boot time,
while keeping the SSR recovery latency reasonable for userspace.

Regarding a more flexible approach: in the current configuration where 
bt_en is pulled high
and the controller self-loads the rampatch/NVM, no HCI event is 
generated by the controller
to indicate firmware load completion.

Without such a notification mechanism, a fixed delay is the only viable 
option at this level.

>
>>>> Steps to reproduce:
>>>> 1. Trigger SSR and wait for SSR to complete:
>>>>      hcitool cmd 0x3f 0c 26
>>>> 2. Run "bluetoothctl power on" and observe that BT fails to start.
>>>>
>>>> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem 
>>>> Restart) fail when BT_EN is pulled up by hw")
>>>> Cc: stable@vger.kernel.org
>>>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>>>> ---
>>>>    drivers/bluetooth/hci_qca.c | 4 ++--
>>>>    1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>>>> index ed280399b..184f52f9c 100644
>>>> --- a/drivers/bluetooth/hci_qca.c
>>>> +++ b/drivers/bluetooth/hci_qca.c
>>>> @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev 
>>>> *hdev, u8 code)
>>>>                mod_timer(&qca->tx_idle_timer, jiffies +
>>>> msecs_to_jiffies(qca->tx_idle_delay));
>>>>
>>>> -             /* Controller reset completion time is 50ms */
>>>> -             msleep(50);
>>>> +             /* Wait for the controller to load the rampatch and 
>>>> NVM.*/
>>>
>>> Missing space at the end.
>>>
>>>> +             msleep(100);
>>>>
>>>>                clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>>>>                clear_bit(QCA_IBS_DISABLED, &qca->flags);
>>>
>>> Is the time it took to load the rampatch and NVM visible in the logs?
>
>
> Kind regards,
>
> Paul


Thanks,

Shuai

Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

[Shuai Zhang]

Hi Paul

Thanks for your review and suggestions.

On 5/22/2026 10:50 PM, Paul Menzel wrote:
> Dear Shuai,
>
>
> Thank you for your patch. Please mention the delay in the 
> summary/title. Maybe:
>
> Use 100 ms SSR delay for rampatch and NVM loading
>
> Am 22.05.26 um 13:08 schrieb Shuai Zhang:
>> When bt_en is pulled high by hardware, the host does not re-download
>> the firmware after SSR. The controller loads the rampatch and NVM
>> internally.
>>
>> On HMT chip, due to the large firmware file size, the
>
> Please document the size (> X MB) 


On HMT chip, the rampatch size is ~264 KB and the NVM is ~9.4 KB.
I will update this information in the next version of the patch.

>
>> loading process takes approximately 70ms. The previous 50ms delay is
>> too short, causing the controller to not respond to the reset command
>> sent by the host, which leads to BT initialization failure.
>
> Maybe paste the log?


  Bluetooth: hci0: QCA memdump Done, received 458752, total 458752
  Bluetooth: hci0: mem_dump_status: 2
  Bluetooth: hci0: Opcode 0x0c03 failed: -110

I will update this information in the next version of the patch.


>
>> Increase the delay to 100ms to ensure the controller has finished
>> loading the firmware before the host sends commands.
>
> Why can’t it be increased to 1 s?
>
>> Steps to reproduce:
>> 1. Trigger SSR and wait for SSR to complete:
>>     hcitool cmd 0x3f 0c 26
>> 2. Run "bluetoothctl power on" and observe that BT fails to start.
>>
>> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) 
>> fail when BT_EN is pulled up by hw")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>> ---
>>   drivers/bluetooth/hci_qca.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index ed280399b..184f52f9c 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev, 
>> u8 code)
>>           mod_timer(&qca->tx_idle_timer, jiffies +
>>                     msecs_to_jiffies(qca->tx_idle_delay));
>>   -        /* Controller reset completion time is 50ms */
>> -        msleep(50);
>> +        /* Wait for the controller to load the rampatch and NVM.*/
>
> Missing space at the end.
>
>> +        msleep(100);
>>             clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>>           clear_bit(QCA_IBS_DISABLED, &qca->flags);
>
> Is the time it took to load the rampatch and NVM visible in the logs?


No, the loading time of the rampatch and NVM is not visible in the host 
logs,

as the firmware is loaded internally by the controller.


>
>
> Kind regards,
>
> Paul


Thanks,

Shuai