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

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

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