[PATCH v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading

[PATCH v2] Bluetooth: hci_qca: Use 100 ms 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, the rampatch is ~264 KB and the NVM is ~9.4 KB. The
loading process takes approximately 70 ms. The previous 50 ms delay is
too short, causing the controller to not respond to the reset command
sent by the host, which leads to BT initialization failure:

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

Increase the delay to 100 ms, which was confirmed as a safe value by
the controller, 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
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
---
Changes in v2:
- Updated subject to mention 100 ms delay value
- Added firmware sizes (~264 KB rampatch, ~9.4 KB NVM)
- Added failure log excerpt
- Explained why 100 ms: confirmed as a safe value by the controller team
- Fixed missing space in comment ('NVM. */')
- Link v1
  https://lore.kernel.org/linux-bluetooth/20260522110838.1158643-1-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..34500137d 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 v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading

[Dmitry Baryshkov]

On Mon, May 25, 2026 at 02:51:56PM +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, the rampatch is ~264 KB and the NVM is ~9.4 KB. The

What is HMT? Don't use abbreviations which are not known outside of your
company.

> loading process takes approximately 70 ms. The previous 50 ms delay is
> too short, causing the controller to not respond to the reset command
> sent by the host, which leads to BT initialization failure:
> 
>  Bluetooth: hci0: QCA memdump Done, received 458752, total 458752
>  Bluetooth: hci0: mem_dump_status: 2
>  Bluetooth: hci0: Opcode 0x0c03 failed: -110
> 
> Increase the delay to 100 ms, which was confirmed as a safe value by
> the controller, 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
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>

-- 
With best wishes
Dmitry

RE: [v2] Bluetooth: hci_qca: Use 100 ms 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=1100263

---Test result---

Test Summary:
CheckPatch                    PASS      0.53 seconds
VerifyFixes                   PASS      0.07 seconds
VerifySignedoff               PASS      0.07 seconds
GitLint                       PASS      0.19 seconds
SubjectPrefix                 PASS      0.06 seconds
BuildKernel                   PASS      26.29 seconds
CheckAllWarning               PASS      29.22 seconds
CheckSparse                   PASS      27.37 seconds
BuildKernel32                 PASS      25.45 seconds
TestRunnerSetup               PASS      574.26 seconds
IncrementalBuild              PASS      25.16 seconds



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

---
Regards,
Linux Bluetooth

Re: [PATCH v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Mon, 25 May 2026 14:51:56 +0800 you 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, the rampatch is ~264 KB and the NVM is ~9.4 KB. The
> loading process takes approximately 70 ms. The previous 50 ms delay is
> too short, causing the controller to not respond to the reset command
> sent by the host, which leads to BT initialization failure:
> 
> [...]

Here is the summary with links:
  - [v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading
    https://git.kernel.org/bluetooth/bluetooth-next/c/b74b39bc6d9d

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html