diff mbox series

Bluetooth: hci_sync: Don't wait peer's reply when powering off

Message ID 20230306170628.1.I8d0612b2968dd4740a4ceaf42f329fb59d5b9324@changeid (mailing list archive)
State Accepted
Commit bc044bb47d5a60eddc1c2d4e66e350869462cd98
Headers show
Series Bluetooth: hci_sync: Don't wait peer's reply when powering off | expand

Checks

Context Check Description
tedd_an/pre-ci_am success Success
tedd_an/CheckPatch success CheckPatch PASS
tedd_an/GitLint success Gitlint PASS
tedd_an/SubjectPrefix success Gitlint PASS
tedd_an/BuildKernel success BuildKernel PASS
tedd_an/CheckAllWarning success CheckAllWarning PASS
tedd_an/CheckSparse success CheckSparse PASS
tedd_an/CheckSmatch success CheckSparse PASS
tedd_an/BuildKernel32 success BuildKernel32 PASS
tedd_an/TestRunnerSetup success TestRunnerSetup PASS
tedd_an/TestRunner_l2cap-tester success TestRunner PASS
tedd_an/TestRunner_iso-tester success TestRunner PASS
tedd_an/TestRunner_bnep-tester success TestRunner PASS
tedd_an/TestRunner_mgmt-tester success TestRunner PASS
tedd_an/TestRunner_rfcomm-tester success TestRunner PASS
tedd_an/TestRunner_sco-tester success TestRunner PASS
tedd_an/TestRunner_ioctl-tester success TestRunner PASS
tedd_an/TestRunner_mesh-tester success TestRunner PASS
tedd_an/TestRunner_smp-tester success TestRunner PASS
tedd_an/TestRunner_userchan-tester success TestRunner PASS
tedd_an/IncrementalBuild success Incremental Build PASS

Commit Message

Archie Pusaka March 6, 2023, 9:07 a.m. UTC
From: Archie Pusaka <apusaka@chromium.org>

Currently, when we initiate disconnection, we will wait for the peer's
reply unless when we are suspending, where we fire and forget the
disconnect request.

A similar case is when adapter is powering off. However, we still wait
for the peer's reply in this case. Therefore, if the peer is
unresponsive, the command will time out and the power off sequence
will fail, causing "bluetooth powered on by itself" to users.

This patch makes the host doesn't wait for the peer's reply when the
disconnection reason is powering off.

Signed-off-by: Archie Pusaka <apusaka@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>

---

 net/bluetooth/hci_sync.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Comments

bluez.test.bot@gmail.com March 6, 2023, 9:35 a.m. UTC | #1
This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=726802

---Test result---

Test Summary:
CheckPatch                    PASS      0.76 seconds
GitLint                       PASS      0.38 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      34.50 seconds
CheckAllWarning               PASS      37.61 seconds
CheckSparse                   PASS      43.06 seconds
CheckSmatch                   PASS      113.89 seconds
BuildKernel32                 PASS      33.61 seconds
TestRunnerSetup               PASS      479.47 seconds
TestRunner_l2cap-tester       PASS      17.60 seconds
TestRunner_iso-tester         PASS      19.19 seconds
TestRunner_bnep-tester        PASS      6.15 seconds
TestRunner_mgmt-tester        PASS      117.87 seconds
TestRunner_rfcomm-tester      PASS      9.63 seconds
TestRunner_sco-tester         PASS      8.56 seconds
TestRunner_ioctl-tester       PASS      10.02 seconds
TestRunner_mesh-tester        PASS      7.34 seconds
TestRunner_smp-tester         PASS      8.42 seconds
TestRunner_userchan-tester    PASS      6.11 seconds
IncrementalBuild              PASS      30.68 seconds



---
Regards,
Linux Bluetooth
Simon Horman March 6, 2023, 12:44 p.m. UTC | #2
On Mon, Mar 06, 2023 at 05:07:07PM +0800, Archie Pusaka wrote:
> From: Archie Pusaka <apusaka@chromium.org>
> 
> Currently, when we initiate disconnection, we will wait for the peer's
> reply unless when we are suspending, where we fire and forget the
> disconnect request.
> 
> A similar case is when adapter is powering off. However, we still wait
> for the peer's reply in this case. Therefore, if the peer is
> unresponsive, the command will time out and the power off sequence
> will fail, causing "bluetooth powered on by itself" to users.
> 
> This patch makes the host doesn't wait for the peer's reply when the
> disconnection reason is powering off.
> 
> Signed-off-by: Archie Pusaka <apusaka@chromium.org>
> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com>

Reviewed-by: Simon Horman <simon.horman@corigine.com>
patchwork-bot+bluetooth@kernel.org March 7, 2023, 6:40 p.m. UTC | #3
Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Mon,  6 Mar 2023 17:07:07 +0800 you wrote:
> From: Archie Pusaka <apusaka@chromium.org>
> 
> Currently, when we initiate disconnection, we will wait for the peer's
> reply unless when we are suspending, where we fire and forget the
> disconnect request.
> 
> A similar case is when adapter is powering off. However, we still wait
> for the peer's reply in this case. Therefore, if the peer is
> unresponsive, the command will time out and the power off sequence
> will fail, causing "bluetooth powered on by itself" to users.
> 
> [...]

Here is the summary with links:
  - Bluetooth: hci_sync: Don't wait peer's reply when powering off
    https://git.kernel.org/bluetooth/bluetooth-next/c/bc044bb47d5a

You are awesome, thank you!
diff mbox series

Patch

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 561a519a11bd6..a6cea389b675f 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -5103,10 +5103,12 @@  static int hci_disconnect_sync(struct hci_dev *hdev, struct hci_conn *conn,
 	cp.handle = cpu_to_le16(conn->handle);
 	cp.reason = reason;
 
-	/* Wait for HCI_EV_DISCONN_COMPLETE not HCI_EV_CMD_STATUS when not
-	 * suspending.
+	/* Wait for HCI_EV_DISCONN_COMPLETE, not HCI_EV_CMD_STATUS, when the
+	 * reason is anything but HCI_ERROR_REMOTE_POWER_OFF. This reason is
+	 * used when suspending or powering off, where we don't want to wait
+	 * for the peer's response.
 	 */
-	if (!hdev->suspended)
+	if (reason != HCI_ERROR_REMOTE_POWER_OFF)
 		return __hci_cmd_sync_status_sk(hdev, HCI_OP_DISCONNECT,
 						sizeof(cp), &cp,
 						HCI_EV_DISCONN_COMPLETE,