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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5kjgeb2a2sugm34io7ikws7xy4jroc7g2jxlrydfc4ipvdpl5z@ckbdxxnjoh2d>
Date: Mon, 15 Sep 2025 15:45:50 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Shuai Zhang <quic_shuaz@...cinc.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

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

-- 
With best wishes
Dmitry