[PATCH 0/4] Fix SSR(Sub-System Restart) issues caused by BT_EN being pulled up by hardware

[PATCH 0/4] Fix SSR(Sub-System Restart) issues caused by BT_EN being pulled up by hardware

[Shuai Zhang]

This patch series addresses issues encountered during SSR when
the BT_EN pin is pulled up by hardware. The main issues fixed are:

1. Timeout when sending reset command.
2. IBS state of host and controller not being synchronized.
3. Multiple triggers of SSR generating only one coredump file.
4. SSR process failed due to tx_idle_timer timeout

Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>


Shuai Zhang (4):
  driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw
  driver: bluetooth: hci_qca: fix host IBS state after SSR
  driver: bluetooth: hci_qca: Multiple triggers of SSR only generate one
    coredump file
  driver: bluetooth: hci_qca: SSR(Sub-System Restart)process failed due
    to tx_idle_timer timeout

 drivers/bluetooth/hci_qca.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

-- 
2.34.1

[PATCH 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Shuai Zhang]

When the host actively triggers SSR and collects coredump data,
the Bluetooth stack sends a reset command to the controller. However,due
to the inability to clear the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits,
the reset command times out.

For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
commit: 740011cfe94859df8d05f5400d589a8693b095e7.

The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP)
because this quirk is associated with BT_EN, and can be used to
determine whether BT_EN is present in the device tree (DTS).

Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
---
 drivers/bluetooth/hci_qca.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4e56782b0..14b2d1bee 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1653,6 +1653,19 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
 		skb_queue_purge(&qca->rx_memdump_q);
 	}
 
+	/* If the BT chip's bt_en pin is always pulled high by a dedicated 3.3V
+	 * power supply via hardware the driver
+	 * cannot control the bt_en pin of the SoC chip, then during SSR,
+	 * the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits cannot be cleared.
+	 * This leads to a reset command timeout failure.
+	 * Also, add msleep delay to wait for controller to complete SSR.
+	 */
+	if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
+		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
+		clear_bit(QCA_IBS_DISABLED, &qca->flags);
+		msleep(50);
+	}
+
 	clear_bit(QCA_HW_ERROR_EVENT, &qca->flags);
 }
 
-- 
2.34.1

[PATCH 2/4] driver: bluetooth: hci_qca: fix host IBS state after SSR

[Shuai Zhang]

After SSR, host will not download the firmware, causing
controller to remain in the IBS_WAKE state. Host needs
to synchronize with the controller to maintain proper operation.

Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
---
 drivers/bluetooth/hci_qca.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 14b2d1bee..50ec9b155 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1659,10 +1659,14 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
 	 * the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits cannot be cleared.
 	 * This leads to a reset command timeout failure.
 	 * Also, add msleep delay to wait for controller to complete SSR.
+	 *
+	 * Host will not download the firmware after SSR, controller to remain
+	 * in the IBS_WAKE state, and the host needs to synchronize with it
 	 */
 	if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
 		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
 		clear_bit(QCA_IBS_DISABLED, &qca->flags);
+		qca->tx_ibs_state = HCI_IBS_TX_AWAKE;
 		msleep(50);
 	}
 
-- 
2.34.1

[PATCH 3/4] driver: bluetooth: hci_qca: Multiple triggers of SSR only generate one coredump file

[Shuai Zhang]

Multiple triggers of SSR only first generate coredump file,
duo to memcoredump_flag no clear.

add clear coredump flag when ssr completed.

Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
---
 drivers/bluetooth/hci_qca.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 50ec9b155..33c2dd7b8 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1662,11 +1662,14 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
 	 *
 	 * Host will not download the firmware after SSR, controller to remain
 	 * in the IBS_WAKE state, and the host needs to synchronize with it
+	 *
+	 * clear memcoredump_flag to ensure next submission of coredump date.
 	 */
 	if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
 		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
 		clear_bit(QCA_IBS_DISABLED, &qca->flags);
 		qca->tx_ibs_state = HCI_IBS_TX_AWAKE;
+		qca->memdump_state = QCA_MEMDUMP_IDLE;
 		msleep(50);
 	}
 
-- 
2.34.1

[PATCH 4/4] driver: bluetooth: hci_qca: SSR(Sub-System Restart)process failed due to tx_idle_timer timeout

[Shuai Zhang]

When the SSR (Sub-System Restart) duration exceeds 2 seconds, it triggers
host tx_idle_timeout, which sets host TX state to sleep. due to the
hardware pulling up bt_en, the firmware is not downloaded after the SSR.
As a result, the controller does not enter sleep mode. Consequently,
when the host sends a command afterward, it sends 0xFD to the controller,
but the controller does not respond, leading to a command timeout.

So reset tx_idle_timer after SSR to prevent host enter TX IBS_Sloeep mode.

Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
---
 drivers/bluetooth/hci_qca.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 33c2dd7b8..1fb8eea09 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1668,6 +1668,15 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
 	if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
 		clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
 		clear_bit(QCA_IBS_DISABLED, &qca->flags);
+		/*
+		 * When the SSR (Sub-System Restart) duration exceeds 2 seconds,
+		 * it triggers host tx_idle_timeout, which sets host TX state
+		 * to sleep. Reset tx_idle_timer after SSR to prevent
+		 * host enter TX IBS_Sloeep mode.
+		 */
+		mod_timer(&qca->tx_idle_timer, jiffies +
+			  msecs_to_jiffies(qca->tx_idle_delay));
+
 		qca->tx_ibs_state = HCI_IBS_TX_AWAKE;
 		qca->memdump_state = QCA_MEMDUMP_IDLE;
 		msleep(50);
-- 
2.34.1

Re: [PATCH 0/4] Fix SSR(Sub-System Restart) issues caused by BT_EN being pulled up by hardware

[Paul Menzel]

Dear Shuai,


Thank you for your patch. In the subject, I’d use the official spelling 
and put a space in *SSR (SubSystem Restart)*, or *SubSystem Restart 
(SSR)* [1].


Kind regards,

Paul


[1]: 
https://docs.qualcomm.com/bundle/publicresource/topics/80-63442-50/htp_ssr.html

Re: [PATCH 0/4] Fix SSR(Sub-System Restart) issues caused by BT_EN being pulled up by hardware

[Shuai Zhang]

Dear Paul,


On 8/12/2025 7:53 PM, Paul Menzel wrote:
> Dear Shuai,
> 
> 
> Thank you for your patch. In the subject, I’d use the official spelling and put a space in *SSR (SubSystem Restart)*, or *SubSystem Restart (SSR)* [1].
> 
> 
> Kind regards,
> 
> Paul
> 
> 
> [1]: https://docs.qualcomm.com/bundle/publicresource/topics/80-63442-50/htp_ssr.html

Thank you for your helpful suggestion. 
I've revised the patch subject to reflect the correct spelling and formatting of 
SubSystem Restart (SSR). I appreciate your time and review.

Kind regards,
Shuai

Re: [PATCH 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Konrad Dybcio]

On 8/12/25 1:36 PM, Shuai Zhang wrote:
> When the host actively triggers SSR and collects coredump data,
> the Bluetooth stack sends a reset command to the controller. However,due
> to the inability to clear the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits,
> the reset command times out.
> 
> For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
> commit: 740011cfe94859df8d05f5400d589a8693b095e7.
> 
> The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP)
> because this quirk is associated with BT_EN, and can be used to
> determine whether BT_EN is present in the device tree (DTS).
> 
> Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
> ---

I have received this series two times, you didn't add a version
prefix (make the next one v3 so as not to confuse the tooling), there
is no changelog and you still haven't added the relevant people to CC.

Please read the internal guidelines at go/upstream and switch to using
the b4 tool.

Konrad

Re: [PATCH 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Dmitry Baryshkov]

On Tue, Aug 12, 2025 at 02:36:24PM +0200, Konrad Dybcio wrote:
> On 8/12/25 1:36 PM, Shuai Zhang wrote:
> > When the host actively triggers SSR and collects coredump data,
> > the Bluetooth stack sends a reset command to the controller. However,due
> > to the inability to clear the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits,
> > the reset command times out.
> > 
> > For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
> > commit: 740011cfe94859df8d05f5400d589a8693b095e7.
> > 
> > The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP)
> > because this quirk is associated with BT_EN, and can be used to
> > determine whether BT_EN is present in the device tree (DTS).
> > 
> > Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
> > ---
> 
> I have received this series two times, you didn't add a version
> prefix (make the next one v3 so as not to confuse the tooling), there
> is no changelog and you still haven't added the relevant people to CC.

To add more on top of that, there were already v1 and v2 several weeks
ago. Please make sure that your versioning is consistent and monothonic.

> Please read the internal guidelines at go/upstream and switch to using
> the b4 tool.

-- 
With best wishes
Dmitry

Re: [PATCH 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Shuai Zhang]

Dear,Konrad

On 8/12/2025 8:36 PM, Konrad Dybcio wrote:
> On 8/12/25 1:36 PM, Shuai Zhang wrote:
>> When the host actively triggers SSR and collects coredump data,
>> the Bluetooth stack sends a reset command to the controller. However,due
>> to the inability to clear the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits,
>> the reset command times out.
>>
>> For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
>> commit: 740011cfe94859df8d05f5400d589a8693b095e7.
>>
>> The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP)
>> because this quirk is associated with BT_EN, and can be used to
>> determine whether BT_EN is present in the device tree (DTS).
>>
>> Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
>> ---
> 
> I have received this series two times, you didn't add a version
> prefix (make the next one v3 so as not to confuse the tooling), there
> is no changelog and you still haven't added the relevant people to CC.
> 
> Please read the internal guidelines at go/upstream and switch to using
> the b4 tool.
> 
> Konrad
I apologize for not including the version number due to my oversight.
I will update it to v3 accordingly. Since the patch has already been 
generated, I won’t use b4 this time. Going forward, 
I will use b4 for all future submissions. Thank you

BR,
Shuai

Re: [PATCH 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Luiz Augusto von Dentz]

Hi Shuai,

On Tue, Aug 12, 2025 at 7:36 AM Shuai Zhang <quic_shuaz@quicinc.com> wrote:
>
> When the host actively triggers SSR and collects coredump data,
> the Bluetooth stack sends a reset command to the controller. However,due
> to the inability to clear the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits,
> the reset command times out.
>
> For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
> commit: 740011cfe94859df8d05f5400d589a8693b095e7.
>
> The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP)
> because this quirk is associated with BT_EN, and can be used to
> determine whether BT_EN is present in the device tree (DTS).
>
> Signed-off-by: Shuai Zhang <quic_shuaz@quicinc.com>
> ---
>  drivers/bluetooth/hci_qca.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 4e56782b0..14b2d1bee 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1653,6 +1653,19 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
>                 skb_queue_purge(&qca->rx_memdump_q);
>         }
>
> +       /* If the BT chip's bt_en pin is always pulled high by a dedicated 3.3V
> +        * power supply via hardware the driver
> +        * cannot control the bt_en pin of the SoC chip, then during SSR,
> +        * the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits cannot be cleared.
> +        * This leads to a reset command timeout failure.
> +        * Also, add msleep delay to wait for controller to complete SSR.
> +        */
> +       if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
> +               clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
> +               clear_bit(QCA_IBS_DISABLED, &qca->flags);
> +               msleep(50);

Ok, I don't know how many times I have indicated that using msleep, or
similar, sort of indicates the driver is blind to the controller
state... also this seems to be assuming that the so called SSR is only
in progress when HCI_QUIRK_NON_PERSISTENT_SETUP? There is also no
explanation about why 50 msec would be enough as well.


> +       }
> +
>         clear_bit(QCA_HW_ERROR_EVENT, &qca->flags);
>  }
>
> --
> 2.34.1
>
>


--
Luiz Augusto von Dentz