On 7/15/25 7:16 AM, Shuai Zhang wrote:
> the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits cannot be cleared.
> This leads to reset command timeout.
This is a description of what goes wrong in terms of the code of
this driver, and it doesn't explain why you gate the code addition
with HCI_QUIRK_NON_PERSISTENT_SETUP, please share more details about
what you're doing, and more importantly, why.
>
> Signed-off-by: Shuai Zhang <quic_shuaz@xxxxxxxxxxx>
> ---
> drivers/bluetooth/hci_qca.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 4e56782b0..791f8d472 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1653,6 +1653,18 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
> skb_queue_purge(&qca->rx_memdump_q);
> }
>
> + /* If the SoC always enables the bt_en pin via hardware and the driver
> + * cannot control the bt_en pin of the SoC chip, then during SSR,
What is the "SoC" here? Bluetooth chip? MSM?
What does "enabling the pin via hardware" refer to? Do we ever expect
that a proper platform description skips the bt_en pin?
Also:
/*
* If the..
> + * the QCA_SSR_TRIGGERED and QCA_IBS_DISABLED bits cannot be cleared.
> + * This leads to a reset command timeout failure.
> + * Also, add msleep delay to wait for controller to complete SSR.
Googling "bluetooth SSR" yields nothing, so it's fair for me to ask
you to explain that acronym.. it's used a number of times across the
driver, so perhaps a comment somewhere at the top in a separate commit
would be good as well. I'm guessing "subsystem reset"?
Konrad
> + */
> + 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);
> + }
> +
> clear_bit(QCA_HW_ERROR_EVENT, &qca->flags);
> }
>
