[PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[Shuai Zhang]

On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw
and cannot be controlled by the host. As a result, in case of a firmware
crash, the host cannot trigger a cold reset. Instead, the BT controller
performs a warm restart on its own, without reloading the firmware.

This leads to the controller remaining in IBS_WAKE state, while the host
expects it to be in sleep mode. The mismatch causes HCI reset commands
to time out. Additionally, the driver does not clear internal flags
QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence.
If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode
due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag
is not cleared, so only the first SSR generates a coredump.

Tell driver that BT controller has undergone a proper restart sequence:

- Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR.
- Add a 50ms delay to allow the controller to complete its warm reset.
- Reset tx_idle_timer to prevent the host from entering TX sleep mode.
- Clear memcoredump_flag to allow multiple coredump captures.

Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set,
which indicates that BT_EN is defined in DTS and cannot be toggled.

Refer to the comment in include/net/bluetooth/hci.h for details on
HCI_QUIRK_NON_PERSISTENT_SETUP.

Changes in v12:
- Rewrote commit to clarify the actual issue and affected platforms.
- Used imperative language to describe the fix.
- Explained the role of HCI_QUIRK_NON_PERSISTENT_SETUP.

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

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4cff4d9be..2d6560482 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1653,6 +1653,39 @@ 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 connected to a 3.3V power supply via
+	 * hardware and always stays high, driver cannot control the bt_en pin.
+	 * As a result, during SSR (SubSystem Restart), QCA_SSR_TRIGGERED and
+	 * QCA_IBS_DISABLED flags cannot be cleared, which leads to a reset
+	 * command timeout.
+	 * Add an msleep delay to ensure controller completes the SSR process.
+	 *
+	 * Host will not download the firmware after SSR, controller to remain
+	 * in the IBS_WAKE state, and the host needs to synchronize with it
+	 *
+	 * Since the bluetooth chip has been reset, clear the memdump state.
+	 */
+	if (!hci_test_quirk(hu->hdev, HCI_QUIRK_NON_PERSISTENT_SETUP)) {
+		/*
+		 * When the SSR (SubSystem Restart) duration exceeds 2 seconds,
+		 * it triggers host tx_idle_delay, which sets host TX state
+		 * to sleep. Reset tx_idle_timer after SSR to prevent
+		 * host enter TX IBS_Sleep mode.
+		 */
+		mod_timer(&qca->tx_idle_timer, jiffies +
+				  msecs_to_jiffies(qca->tx_idle_delay));
+
+		/* Controller reset completion time is 50ms */
+		msleep(50);
+
+		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;
+	}
+
 	clear_bit(QCA_HW_ERROR_EVENT, &qca->flags);
 }
 
-- 
2.34.1

Re: [PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[kernel test robot]

Hi,

Thanks for your patch.

FYI: kernel test robot notices the stable kernel rule is not satisfied.

The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw
Link: https://lore.kernel.org/stable/20250916140259.400285-1-quic_shuaz%40quicinc.com

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[Dmitry Baryshkov]

On Tue, Sep 16, 2025 at 10:02:59PM +0800, Shuai Zhang wrote:
> On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw
> and cannot be controlled by the host. As a result, in case of a firmware
> crash, the host cannot trigger a cold reset. Instead, the BT controller
> performs a warm restart on its own, without reloading the firmware.
> 
> This leads to the controller remaining in IBS_WAKE state, while the host
> expects it to be in sleep mode. The mismatch causes HCI reset commands
> to time out. Additionally, the driver does not clear internal flags
> QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence.
> If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode
> due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag
> is not cleared, so only the first SSR generates a coredump.
> 
> Tell driver that BT controller has undergone a proper restart sequence:
> 
> - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR.
> - Add a 50ms delay to allow the controller to complete its warm reset.
> - Reset tx_idle_timer to prevent the host from entering TX sleep mode.
> - Clear memcoredump_flag to allow multiple coredump captures.
> 
> Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set,
> which indicates that BT_EN is defined in DTS and cannot be toggled.
> 
> Refer to the comment in include/net/bluetooth/hci.h for details on
> HCI_QUIRK_NON_PERSISTENT_SETUP.
> 
> Changes in v12:
> - Rewrote commit to clarify the actual issue and affected platforms.
> - Used imperative language to describe the fix.
> - Explained the role of HCI_QUIRK_NON_PERSISTENT_SETUP.

I'll leave having the changelog inside the commit message to the
maintainer's discretion.

Otherwise:


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



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

-- 
With best wishes
Dmitry

Re: [PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[Shuai Zhang]

Hi Luiz

On 9/16/2025 11:01 PM, Dmitry Baryshkov wrote:
> On Tue, Sep 16, 2025 at 10:02:59PM +0800, Shuai Zhang wrote:
>> On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw
>> and cannot be controlled by the host. As a result, in case of a firmware
>> crash, the host cannot trigger a cold reset. Instead, the BT controller
>> performs a warm restart on its own, without reloading the firmware.
>>
>> This leads to the controller remaining in IBS_WAKE state, while the host
>> expects it to be in sleep mode. The mismatch causes HCI reset commands
>> to time out. Additionally, the driver does not clear internal flags
>> QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence.
>> If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode
>> due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag
>> is not cleared, so only the first SSR generates a coredump.
>>
>> Tell driver that BT controller has undergone a proper restart sequence:
>>
>> - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR.
>> - Add a 50ms delay to allow the controller to complete its warm reset.
>> - Reset tx_idle_timer to prevent the host from entering TX sleep mode.
>> - Clear memcoredump_flag to allow multiple coredump captures.
>>
>> Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set,
>> which indicates that BT_EN is defined in DTS and cannot be toggled.
>>
>> Refer to the comment in include/net/bluetooth/hci.h for details on
>> HCI_QUIRK_NON_PERSISTENT_SETUP.
>>
>> Changes in v12:
>> - Rewrote commit to clarify the actual issue and affected platforms.
>> - Used imperative language to describe the fix.
>> - Explained the role of HCI_QUIRK_NON_PERSISTENT_SETUP.
> 
> I'll leave having the changelog inside the commit message to the
> maintainer's discretion.
> 
> Otherwise:
> 
> 
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> 
> 

I noticed that this upstream patch has already been reviewed,
but it still seems not to have been accepted. Is there anything else I need to do?

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

Thanks,
Shuai

Re: [PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[Luiz Augusto von Dentz]

Hi Shuai,

On Tue, Dec 2, 2025 at 4:08 AM Shuai Zhang <quic_shuaz@quicinc.com> wrote:
>
> Hi Luiz
>
> On 9/16/2025 11:01 PM, Dmitry Baryshkov wrote:
> > On Tue, Sep 16, 2025 at 10:02:59PM +0800, Shuai Zhang wrote:
> >> On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw
> >> and cannot be controlled by the host. As a result, in case of a firmware
> >> crash, the host cannot trigger a cold reset. Instead, the BT controller
> >> performs a warm restart on its own, without reloading the firmware.
> >>
> >> This leads to the controller remaining in IBS_WAKE state, while the host
> >> expects it to be in sleep mode. The mismatch causes HCI reset commands
> >> to time out. Additionally, the driver does not clear internal flags
> >> QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence.
> >> If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode
> >> due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag
> >> is not cleared, so only the first SSR generates a coredump.
> >>
> >> Tell driver that BT controller has undergone a proper restart sequence:
> >>
> >> - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR.
> >> - Add a 50ms delay to allow the controller to complete its warm reset.
> >> - Reset tx_idle_timer to prevent the host from entering TX sleep mode.
> >> - Clear memcoredump_flag to allow multiple coredump captures.
> >>
> >> Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set,
> >> which indicates that BT_EN is defined in DTS and cannot be toggled.
> >>
> >> Refer to the comment in include/net/bluetooth/hci.h for details on
> >> HCI_QUIRK_NON_PERSISTENT_SETUP.
> >>
> >> Changes in v12:
> >> - Rewrote commit to clarify the actual issue and affected platforms.
> >> - Used imperative language to describe the fix.
> >> - Explained the role of HCI_QUIRK_NON_PERSISTENT_SETUP.
> >
> > I'll leave having the changelog inside the commit message to the
> > maintainer's discretion.
> >
> > Otherwise:
> >
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> >
> >
>
> I noticed that this upstream patch has already been reviewed,
> but it still seems not to have been accepted. Is there anything else I need to do?

My bad, please resend it so CI can pick it up for testing.

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



-- 
Luiz Augusto von Dentz

Re: [PATCH v12] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw

[Shuai Zhang]

Hi Luiz

On 12/2/2025 10:30 PM, Luiz Augusto von Dentz wrote:
> Hi Shuai,
> 
> On Tue, Dec 2, 2025 at 4:08 AM Shuai Zhang <quic_shuaz@quicinc.com> wrote:
>>
>> Hi Luiz
>>
>> On 9/16/2025 11:01 PM, Dmitry Baryshkov wrote:
>>> On Tue, Sep 16, 2025 at 10:02:59PM +0800, Shuai Zhang wrote:
>>>> On QCS9075 and QCA8275 platforms, the BT_EN pin is always pulled up by hw
>>>> and cannot be controlled by the host. As a result, in case of a firmware
>>>> crash, the host cannot trigger a cold reset. Instead, the BT controller
>>>> performs a warm restart on its own, without reloading the firmware.
>>>>
>>>> This leads to the controller remaining in IBS_WAKE state, while the host
>>>> expects it to be in sleep mode. The mismatch causes HCI reset commands
>>>> to time out. Additionally, the driver does not clear internal flags
>>>> QCA_SSR_TRIGGERED and QCA_IBS_DISABLED, which blocks the reset sequence.
>>>> If the SSR duration exceeds 2 seconds, the host may enter TX sleep mode
>>>> due to tx_idle_timeout, further preventing recovery. Also, memcoredump_flag
>>>> is not cleared, so only the first SSR generates a coredump.
>>>>
>>>> Tell driver that BT controller has undergone a proper restart sequence:
>>>>
>>>> - Clear QCA_SSR_TRIGGERED and QCA_IBS_DISABLED flags after SSR.
>>>> - Add a 50ms delay to allow the controller to complete its warm reset.
>>>> - Reset tx_idle_timer to prevent the host from entering TX sleep mode.
>>>> - Clear memcoredump_flag to allow multiple coredump captures.
>>>>
>>>> Apply these steps only when HCI_QUIRK_NON_PERSISTENT_SETUP is not set,
>>>> which indicates that BT_EN is defined in DTS and cannot be toggled.
>>>>
>>>> Refer to the comment in include/net/bluetooth/hci.h for details on
>>>> HCI_QUIRK_NON_PERSISTENT_SETUP.
>>>>
>>>> Changes in v12:
>>>> - Rewrote commit to clarify the actual issue and affected platforms.
>>>> - Used imperative language to describe the fix.
>>>> - Explained the role of HCI_QUIRK_NON_PERSISTENT_SETUP.
>>>
>>> I'll leave having the changelog inside the commit message to the
>>> maintainer's discretion.
>>>
>>> Otherwise:
>>>
>>>
>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>
>>>
>>
>> I noticed that this upstream patch has already been reviewed,
>> but it still seems not to have been accepted. Is there anything else I need to do?
> 
> My bad, please resend it so CI can pick it up for testing.
> 

I have resubmitted a new patch, please help review it.

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

Thanks,
Shuai

>