[PW_SID:1079179] [v5] Bluetooth: qca: Fix delayed hw_error handling due to missing wakeup during SSR#3467
[PW_SID:1079179] [v5] Bluetooth: qca: Fix delayed hw_error handling due to missing wakeup during SSR#3467BluezTestBot wants to merge 1 commit intoworkflowfrom
Conversation
…uring SSR 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. 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 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`. - 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. Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
|
CheckPatch |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
TestRunnerSetup |
|
TestRunner_l2cap-tester |
|
TestRunner_iso-tester |
|
TestRunner_bnep-tester |
|
TestRunner_mgmt-tester |
|
TestRunner_rfcomm-tester |
|
TestRunner_sco-tester |
|
TestRunner_ioctl-tester |
|
TestRunner_mesh-tester |
|
TestRunner_smp-tester |
|
TestRunner_userchan-tester |
|
IncrementalBuild |
2 participants
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.
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 finishesprocessing 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:
hcitool cmd 0x3f 0c 26.btmonto capture HCI logs.and the execution of the power-off sequence in the HCI log.
Signed-off-by: Shuai Zhang shuai.zhang@oss.qualcomm.com
Changes v5:
https://lore.kernel.org/all/20260327083258.1398450-1-shuai.zhang@oss.qualcomm.com/
Changes v4:
https://lore.kernel.org/all/20251107033924.3707495-1-quic_shuaz@quicinc.com/
Changes v3:
https://lore.kernel.org/all/20251106140103.1406081-1-quic_shuaz@quicinc.com/
Changes v2:
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(-)