On 8/13/25 1:28 PM, Shuai Zhang wrote: > Hi, Konrad > > On 8/13/2025 7:05 PM, Konrad Dybcio wrote: >> On 8/13/25 5:35 AM, Shuai Zhang 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 >> >> weird line break >> >>> + * cannot control the bt_en pin of the SoC chip, then during SSR, >> >> "System on a Chip chip" > > I will modify. > >> >>> + * 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. >> >> 50 is a random value, I also see 300, 100 across the driver.. where does it >> come from? >> > The controller requires 50ms to stabilize after power-on, > so we wait 50ms after the coredump completes Is that common for all controllers supported by this driver? Please #define this value somewhere Konrad
