[PW_SID:1069868] Bluetooth: btusb: cancel pending HCI commands before USB suspend#3387
[PW_SID:1069868] Bluetooth: btusb: cancel pending HCI commands before USB suspend#3387BluezTestBot wants to merge 2 commits intoworkflowfrom
Conversation
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
During system suspend, the PM notifier and USB subsystem suspend run concurrently without synchronization. If the PM notifier's hci_power_off_sync() is blocked waiting for an HCI command response (e.g., Write Scan Enable, opcode 0x0c1a) when the USB subsystem tears down the device, the command fails with -ENODEV. Unlike a timeout (-ETIMEDOUT), an ENODEV cancellation does not trigger hci_cmd_timeout(), which means hdev->reset() is never called and the Intel ACPI reset method (_PRR/_RST) that would recover the device is bypassed. The device then fails to re-enumerate on resume (detected as low-speed instead of full-speed, error -71) and is permanently lost until the xHCI host controller is reset or the system is rebooted. Cancel any pending synchronous HCI commands in btusb_suspend() before btusb_stop_traffic() kills the URBs, but only for non-autosuspend (system suspend). This matches the pattern used by hci_suspend_dev() which calls hci_cancel_cmd_sync(hdev, EHOSTDOWN) before proceeding with HCI-level suspend. Signed-off-by: Frederik Berg <fberg@posteo.de>
|
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 |
github-actions
bot
force-pushed
the
workflow
branch
5 times, most recently
from
9f31ee4 to
19dcf1f
Compare
github-actions
bot
force-pushed
the
workflow
branch
4 times, most recently
from
9dddb3f to
c6e7062
Compare
github-actions
bot
force-pushed
the
workflow
branch
2 times, most recently
from
0e0806d to
f465113
Compare
3 participants
During system suspend, the PM notifier and USB subsystem suspend run
concurrently without synchronization. If the PM notifier's
hci_power_off_sync() is blocked waiting for an HCI command response
(e.g., Write Scan Enable, opcode 0x0c1a) when the USB subsystem tears
down the device, the command fails with -ENODEV.
Unlike a timeout (-ETIMEDOUT), an ENODEV cancellation does not trigger
hci_cmd_timeout(), which means hdev->reset() is never called and the
Intel ACPI reset method (_PRR/_RST) that would recover the device is
bypassed. The device then fails to re-enumerate on resume (detected as
low-speed instead of full-speed, error -71) and is permanently lost
until the xHCI host controller is reset or the system is rebooted.
Cancel any pending synchronous HCI commands in btusb_suspend() before
btusb_stop_traffic() kills the URBs, but only for non-autosuspend
(system suspend). This matches the pattern used by hci_suspend_dev()
which calls hci_cancel_cmd_sync(hdev, EHOSTDOWN) before proceeding
with HCI-level suspend.
Signed-off-by: Frederik Berg fberg@posteo.de
Proposed fix for the race described in the parent email. This cancels
any pending synchronous HCI commands in btusb_suspend() before
btusb_stop_traffic() kills the URBs, preventing the race. Only for
system suspend, not autosuspend. Same pattern used by hci_suspend_dev()
which calls hci_cancel_cmd_sync(hdev, EHOSTDOWN).
I haven't been able to build-test this against a running kernel yet,
so consider this an RFC.
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)