Re: [PATCH 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]

 



Hi Shuai,

On Tue, Aug 12, 2025 at 7:36 AM Shuai Zhang <quic_shuaz@xxxxxxxxxxx> 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.
>
> For the purpose of HCI_QUIRK_NON_PERSISTENT_SETUP, please refer to
> commit: 740011cfe94859df8d05f5400d589a8693b095e7.
>
> The change is placed under if (!HCI_QUIRK_NON_PERSISTENT_SETUP)
> because this quirk is associated with BT_EN, and can be used to
> determine whether BT_EN is present in the device tree (DTS).
>
> Signed-off-by: Shuai Zhang <quic_shuaz@xxxxxxxxxxx>
> ---
>  drivers/bluetooth/hci_qca.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 4e56782b0..14b2d1bee 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1653,6 +1653,19 @@ 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 always pulled high by a dedicated 3.3V
> +        * power supply via hardware the driver
> +        * cannot control the bt_en pin of the SoC chip, then during SSR,
> +        * 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.
> +        */
> +       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);

Ok, I don't know how many times I have indicated that using msleep, or
similar, sort of indicates the driver is blind to the controller
state... also this seems to be assuming that the so called SSR is only
in progress when HCI_QUIRK_NON_PERSISTENT_SETUP? There is also no
explanation about why 50 msec would be enough as well.


> +       }
> +
>         clear_bit(QCA_HW_ERROR_EVENT, &qca->flags);
>  }
>
> --
> 2.34.1
>
>


--
Luiz Augusto von Dentz





[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