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

[Shuai Zhang]

Hi Dmitry

On 9/15/2025 8:45 PM, Dmitry Baryshkov wrote:
> On Wed, Aug 27, 2025 at 06:25:19PM +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.
> 
> Why? Does it apply to all platforms (as it seems from your text)?
> 
> Please write the commit message in the form that is easy to
> udnerstand for somebody who doesn't know Qualcomm _specifics_.
> 
> - Decribe the issue first. The actual issue, not just the symtoms.
>   Provide enough details to understand whether the issue applies to one
>   platform, to a set of platforms or to all platforms.
> 
> - Describe what needs to be done. Use imperative language (see
>   Documentation/process/submitting-patches.rst). Don't use phrases like
>   'This patch does' or 'This change does'.
> 
>>
>> To address this, this patch clears the QCA_SSR_TRIGGERED and
>> QCA_IBS_DISABLED flags and adds a 50ms delay after SSR, but only when
>> HCI_QUIRK_NON_PERSISTENT_SETUP is not set. This ensures the controller
>> completes the SSR process when BT_EN is always high due to hardware.
>>
>> For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
>> the comment in `include/net/bluetooth/hci.h`.
> 
> Which comment?
> 
>>
>> The HCI_QUIRK_NON_PERSISTENT_SETUP quirk is associated with BT_EN,
>> and its presence can be used to determine whether BT_EN is defined in DTS.
>>
>> 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.
>>
>> Multiple triggers of SSR only first generate coredump file,
>> due to memcoredump_flag no clear.
>>
>> add clear coredump flag when ssr completed.
>>
>> When the SSR 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_Sleep mode.
> 
> The whole commit message can be formulated as:
> 
> On XYZ there is no way to control BT_EN pin and as such trigger a cold
> reset in case of firmware crash. The BT chip performs a warm restart on
> its own (without reloading the firmware, foo, bar baz). This triggers
> bar baz foo in the driver. Tell the driver that the BT controller has
> undergone a proper restart sequence:
> 
> - Foo
> 
> - Bar
> 
> - Baz
> 
Appreciate your patient guidance. I have implemented and integrated
the proposed changes into v12, and it awaits your review.

BR,
Shuai