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 Awaiting Upstream
Delegated to: Netdev Maintainers
Headers show
Series Bluetooth: hci_sync: Don't wait peer's reply when powering off | expand

Checks

Context Check Description
netdev/series_format warning Single patches do not need cover letters; Target tree name not specified in the subject
netdev/tree_selection success Guessed tree name to be net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 9 of 9 maintainers
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 15 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

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

Simon Horman March 6, 2023, 12:44 p.m. UTC | #1 
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 | #2 
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,