Hi Dmitry
On 8/16/2025 5:48 AM, Dmitry Baryshkov wrote:
> 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);
>> }
Thank you for your suggestion. I will update accordingly.
BR,
Shuai
