linux-kernel - Re: [PATCH v11] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0b1f0a51-3bed-4e66-9285-61f110707ebf@quicinc.com>
Date: Tue, 16 Sep 2025 22:02:51 +0800
From: Shuai Zhang <quic_shuaz@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: <marcel@...tmann.org>, <luiz.dentz@...il.com>,
        <linux-bluetooth@...r.kernel.org>, <stable@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <quic_chejiang@...cinc.com>
Subject: Re: [PATCH v11] Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail
 when BT_EN is pulled up by hw

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