Re: [PATCH v4 1/4] driver: bluetooth: hci_qca: fix ssr fail when BT_EN is pulled up by hw

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux