From: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Bartosz Golaszewski <brgl@kernel.org>,
Marcel Holtmann <marcel@holtmann.org>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
linux-arm-msm@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, cheng.jiang@oss.qualcomm.com,
quic_chezhou@quicinc.com, wei.deng@oss.qualcomm.com,
jinwang.li@oss.qualcomm.com, mengshi.wu@oss.qualcomm.com,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Subject: Re: [PATCH v6] Bluetooth: qca: Fix delayed hw_error handling due to missing wakeup during SSR
Date: Fri, 10 Apr 2026 17:55:58 +0800 [thread overview]
Message-ID: <f29c2a2a-5b02-46c1-bd6c-fa337faf8370@oss.qualcomm.com> (raw)
In-Reply-To: <489d33f4-16a1-430c-9ec6-7f13a8f2f995@molgen.mpg.de>
Hi Paul
Thank you for the suggestion. I have updated it in v7.
On 4/10/2026 5:38 PM, Paul Menzel wrote:
> Dear Shuai,
>
>
> Thank you for your patch. Just some last style things. It’d be great
> if you could re-flow the commit message to 75 characters per line.
> This would save some lines.
>
> Am 10.04.26 um 10:52 schrieb Shuai Zhang:
>> When Bluetooth controller encounters a coredump, it triggers
>> the Subsystem Restart (SSR) mechanism. The controller first
>> reports the coredump data, and once the data upload is complete,
>> it sends a hw_error event. The host relies on this event to
>> proceed with subsequent recovery actions.
>>
>> If the host has not finished processing the coredump data
>> when the hw_error event is received,
>> it sets a timer to wait until either the data processing is complete
>> or the timeout expires before handling the event.
>
> Maybe mention the timer value?
>
>> The current implementation lacks a wakeup trigger. As a result,
>> even if the coredump data has already been processed, the host
>> continues to wait until the timer expires, causing unnecessary
>> delays in handling the hw_error event.
>>
>> To fix this issue, adds a `wake_up_bit()` call after the host finishes
>
> s/adds/add/
>
> Now that you use `clear_and_wake_up_bit()`, this might confuse
> readers. Maybe:
>
> To fix this issue, also wake up the other thread by using
> `clear_and_wake_up_bit()`.
>
> Feel free to ignore though.
>
>> processing the coredump data. This ensures that the waiting thread is
>> promptly notified and can proceed to handle the hw_error event without
>> waiting for the timeout.
>>
>> Test case:
>> - Trigger controller coredump using the command: `hcitool cmd 0x3f 0c
>> 26`.
>
> It’d be great if you mentioned one affected controller.
>
>> - Use `btmon` to capture HCI logs.
>> - Observe the time interval between receiving the hw_error event
>> and the execution of the power-off sequence in the HCI log.
>
> Please paste the logs.
>
>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>> ---
>> Changes v6:
>> - Replace wake_up_bit with clear_and_wake_up_bit
>> - Link to v5
>> https://lore.kernel.org/all/20260409112233.3326467-1-shuai.zhang@oss.qualcomm.com/
>>
>> Changes v5:
>> - Replace clear_and_wake_up_bit with wake_up_bit
>> - Link to v4
>> https://lore.kernel.org/all/20260327083258.1398450-1-shuai.zhang@oss.qualcomm.com/
>>
>> Changes v4:
>> - add Acked-by signoff
>> - Link to v3
>> https://lore.kernel.org/all/20251107033924.3707495-1-quic_shuaz@quicinc.com/
>>
>> Changes v3:
>> - add Fixes tag
>> - Link to v2
>> https://lore.kernel.org/all/20251106140103.1406081-1-quic_shuaz@quicinc.com/
>>
>> Changes v2:
>> - Split timeout conversion into a separate patch.
>> - Clarified commit messages and added test case description.
>> - Link to v1
>> https://lore.kernel.org/all/20251104112601.2670019-1-quic_shuaz@quicinc.com/
>> ---
>> drivers/bluetooth/hci_qca.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index c17a462ae..228a754a9 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1108,7 +1108,7 @@ static void qca_controller_memdump(struct
>> work_struct *work)
>> qca->qca_memdump = NULL;
>> qca->memdump_state = QCA_MEMDUMP_COLLECTED;
>> cancel_delayed_work(&qca->ctrl_memdump_timeout);
>> - clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
>> + clear_and_wake_up_bit(QCA_MEMDUMP_COLLECTION,
>> &qca->flags);
>> clear_bit(QCA_IBS_DISABLED, &qca->flags);
>> mutex_unlock(&qca->hci_memdump_lock);
>> return;
>> @@ -1186,7 +1186,7 @@ static void qca_controller_memdump(struct
>> work_struct *work)
>> kfree(qca->qca_memdump);
>> qca->qca_memdump = NULL;
>> qca->memdump_state = QCA_MEMDUMP_COLLECTED;
>> - clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
>> + clear_and_wake_up_bit(QCA_MEMDUMP_COLLECTION, &qca->flags);
>> }
>> mutex_unlock(&qca->hci_memdump_lock);
>
> With the comments above addressed:
>
> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
>
>
> Kind regards,
>
> Paul
>
>
> PS: gemini/gemini-3.1-pro-preview has some unrelated(?) comments [1].
> It’d be great if Qualcomm could look into this.
>
>
> [1]:
> https://sashiko.dev/#/patchset/20260410085202.4128000-1-shuai.zhang%40oss.qualcomm.com
>
Thanks,
shuai
next prev parent reply other threads:[~2026-04-10 9:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 8:52 [PATCH v6] Bluetooth: qca: Fix delayed hw_error handling due to missing wakeup during SSR Shuai Zhang
2026-04-10 9:38 ` Paul Menzel
2026-04-10 9:55 ` Shuai Zhang [this message]
2026-04-10 10:17 ` [v6] " bluez.test.bot
2026-04-10 14:20 ` [PATCH v6] " patchwork-bot+bluetooth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f29c2a2a-5b02-46c1-bd6c-fa337faf8370@oss.qualcomm.com \
--to=shuai.zhang@oss.qualcomm.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=brgl@kernel.org \
--cc=cheng.jiang@oss.qualcomm.com \
--cc=jinwang.li@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=mengshi.wu@oss.qualcomm.com \
--cc=pmenzel@molgen.mpg.de \
--cc=quic_chezhou@quicinc.com \
--cc=wei.deng@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox