On Thu, Aug 14, 2025 at 08:47:01PM +0800, Shuai Zhang wrote: I wonder what does it make to notice the part of the BT test report: SubjectPrefix FAIL 0.66 seconds and update log messages according to the custom of the BT subsystem? Please use 'git log drivers/bluetooth/hci_qca.c' if you are unsure. > 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. > > For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to > commit: 740011cfe94859df8d05f5400d589a8693b095e7. commit 740011cfe948 ("Bluetooth: Add new quirk for non-persistent setup settings") > > The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP) Which change? You've described the issue, but you didn't describe what is to be done. > because this quirk is associated with BT_EN, and can be used to > determine whether BT_EN is present in the device tree (DTS). What can be 'used to determine....' ? > > Signed-off-by: Shuai Zhang <quic_shuaz@xxxxxxxxxxx> > --- > drivers/bluetooth/hci_qca.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c > index 4e56782b0..91009c6a7 100644 > --- a/drivers/bluetooth/hci_qca.c > +++ b/drivers/bluetooth/hci_qca.c > @@ -1653,6 +1653,20 @@ 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. > + */ > + if (!test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) { > + clear_bit(QCA_SSR_TRIGGERED, &qca->flags); > + clear_bit(QCA_IBS_DISABLED, &qca->flags); > + msleep(50); It should be done other way around: first sleep, then clear bits. Otherwise userspace might start sending SKBs while the BT is still recovering. > + } > + > clear_bit(QCA_HW_ERROR_EVENT, &qca->flags); > } -- With best wishes Dmitry