Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

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

Posted by Shuai Zhang 2 days, 6 hours ago

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: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading

Posted by Paul Menzel 2 days, 2 hours ago

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

Posted by Luiz Augusto von Dentz 2 days, 1 hour ago

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

Posted by Paul Menzel 1 day, 21 hours ago

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

Posted by Dmitry Baryshkov 2 days, 3 hours ago

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