Hi, Dmitry
On 8/22/2025 7:44 PM, Dmitry Baryshkov wrote:
> On Thu, Aug 21, 2025 at 08:16:26PM +0800, 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.
>
> [...]
>
>>
>> Signed-off-by: Shuai Zhang <quic_shuaz@xxxxxxxxxxx>
>> ---
>> drivers/bluetooth/hci_qca.c | 33 +++++++++++++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>
> Missing changelog between versions.
>
I will update>>
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index 4e56782b0..9dc59b002 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 (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
>
> And it didn't improve...
Sorry, Due to my oversight, I mistakenly resent v6.
I will apply the modifications and update to v8.
BR,
Shuai>
>
