[PATCH v3 0/4] Fix SSR(SubSystem Restart) issues caused by BT_EN being pulled up by hardware

[PATCH v3 0/4] Fix SSR(SubSystem 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>
---
To: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: quic_bt@quicinc.com

---
Changes in v2:
- Update commit messages.
- Add version number.
- Add new change 4/4 patch to fix Idle_timer timeout.
- Link to v1/2: https://lore.kernel.org/all/20250715051618.724475-1-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(SubSystem Restart)process failed due
    to tx_idle_timer timeout

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

-- 
2.34.1

[PATCH v3 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 v3 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 v3 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 v3 4/4] driver: bluetooth: hci_qca: SSR(SubSystem Restart)process failed due to tx_idle_timer timeout

[Shuai Zhang]

When the SSR (SubSystem 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 v3 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Konrad Dybcio]

On 8/13/25 5:35 AM, 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>
> ---
>  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

weird line break

> +	 * cannot control the bt_en pin of the SoC chip, then during SSR,

"System on a Chip chip"

> +	 * 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.

50 is a random value, I also see 300, 100 across the driver.. where does it
come from?

Konrad

> +	 */
> +	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);
>  }
>  

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

[Konrad Dybcio]

On 8/13/25 5:35 AM, Shuai Zhang wrote:
> 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>
> ---

Please read

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes

and adjust your commit message accordingly.

>  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.

"Since the bluetooth chip has been reset, clear the memdump state"

Konrad

>  	 */
>  	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);
>  	}
>  

Re: [PATCH v3 4/4] driver: bluetooth: hci_qca: SSR(SubSystem Restart)process failed due to tx_idle_timer timeout

[Konrad Dybcio]

On 8/13/25 5:35 AM, Shuai Zhang wrote:
> When the SSR (SubSystem Restart) duration exceeds 2 seconds, it triggers
> host tx_idle_timeout, which sets host TX state to sleep. due to the

Host? Looks like we're sending a command to the BT chip and that
triggers the issue

> 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,

This comment will become out of date quickly, refer to 'tx_idle_delay' instead

Konrad

> +		 * 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);

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

[Shuai Zhang]

Hi, Konrad

On 8/13/2025 7:05 PM, Konrad Dybcio wrote:
> On 8/13/25 5:35 AM, 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>
>> ---
>>  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
> 
> weird line break
> 
>> +	 * cannot control the bt_en pin of the SoC chip, then during SSR,
> 
> "System on a Chip chip"

I will modify.

> 
>> +	 * 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.
> 
> 50 is a random value, I also see 300, 100 across the driver.. where does it
> come from?
> 
The controller requires 50ms to stabilize after power-on,
so we wait 50ms after the coredump completes

> Konrad
> 
>> +	 */
>> +	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);
>>  }
>>  

BR,
Shuai

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

[Shuai Zhang]

Hi,Konrad

On 8/13/2025 7:11 PM, Konrad Dybcio wrote:
> On 8/13/25 5:35 AM, Shuai Zhang wrote:
>> 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>
>> ---
> 
> Please read
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
> 
> and adjust your commit message accordingly.
> 
>>  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.
> 
> "Since the bluetooth chip has been reset, clear the memdump state"
> 
> Konrad
> 

I will update.

>>  	 */
>>  	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);
>>  	}
>>  

BR,
Shuai

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

[Konrad Dybcio]

On 8/13/25 1:28 PM, Shuai Zhang wrote:
> Hi, Konrad
> 
> On 8/13/2025 7:05 PM, Konrad Dybcio wrote:
>> On 8/13/25 5:35 AM, 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>
>>> ---
>>>  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
>>
>> weird line break
>>
>>> +	 * cannot control the bt_en pin of the SoC chip, then during SSR,
>>
>> "System on a Chip chip"
> 
> I will modify.
> 
>>
>>> +	 * 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.
>>
>> 50 is a random value, I also see 300, 100 across the driver.. where does it
>> come from?
>>
> The controller requires 50ms to stabilize after power-on,
> so we wait 50ms after the coredump completes

Is that common for all controllers supported by this driver?

Please #define this value somewhere

Konrad

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

[Shuai Zhang]

On 8/13/2025 7:32 PM, Konrad Dybcio wrote:
> On 8/13/25 1:28 PM, Shuai Zhang wrote:
>> Hi, Konrad
>>
>> On 8/13/2025 7:05 PM, Konrad Dybcio wrote:
>>> On 8/13/25 5:35 AM, 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>
>>>> ---
>>>>  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
>>>
>>> weird line break
>>>
>>>> +	 * cannot control the bt_en pin of the SoC chip, then during SSR,
>>>
>>> "System on a Chip chip"
>>
>> I will modify.
>>
>>>
>>>> +	 * 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.
>>>
>>> 50 is a random value, I also see 300, 100 across the driver.. where does it
>>> come from?
>>>
>> The controller requires 50ms to stabilize after power-on,
>> so we wait 50ms after the coredump completes
> 
> Is that common for all controllers supported by this driver?
> 
> Please #define this value somewhere

Not all controllers require a stabilization period after power-on.
However, if it is needed, 50ms is sufficient.

> 
> Konrad

Re: [PATCH v3 4/4] driver: bluetooth: hci_qca: SSR(SubSystem Restart)process failed due to tx_idle_timer timeout

[Shuai Zhang]

Dear,Konrad

On 8/13/2025 7:13 PM, Konrad Dybcio wrote:
> On 8/13/25 5:35 AM, Shuai Zhang wrote:
>> When the SSR (SubSystem Restart) duration exceeds 2 seconds, it triggers
>> host tx_idle_timeout, which sets host TX state to sleep. due to the
> 
> Host? Looks like we're sending a command to the BT chip and that
> triggers the issue

Since the firmware is not downloaded after ssR, the controller does not enter
the ibs_sleep state. If the host enters ibs_sleep, it will send a wake-up 
command before sending any other commands. 

However, the controller only processes IBS wake-up commands when it is already
in ibs_sleep. As a result, it will not respond to the host's wake-up command,
which prevents host from send actual command and leads to a send command timeout.

Therefore, the host must not enter the ibs_sleep state.

> 
>> 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,
> 
> This comment will become out of date quickly, refer to 'tx_idle_delay' instead
> 

i will update.

> Konrad
> 
>> +		 * 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);

BR,
Shuai