* [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off
@ 2023-03-06 9:07 Archie Pusaka
2023-03-06 9:35 ` bluez.test.bot
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Archie Pusaka @ 2023-03-06 9:07 UTC (permalink / raw)
To: linux-bluetooth, Luiz Augusto von Dentz, Marcel Holtmann
Cc: CrosBT Upstreaming, Archie Pusaka, Abhishek Pandit-Subedi,
David S. Miller, Eric Dumazet, Jakub Kicinski, Johan Hedberg,
Paolo Abeni, linux-kernel, netdev
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(-)
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,
--
2.40.0.rc0.216.gc4246ad0f0-goog
^ permalink raw reply related [flat|nested] 4+ messages in thread* RE: Bluetooth: hci_sync: Don't wait peer's reply when powering off
2023-03-06 9:07 [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off Archie Pusaka
@ 2023-03-06 9:35 ` bluez.test.bot
2023-03-06 12:44 ` [PATCH] " Simon Horman
2023-03-07 18:40 ` patchwork-bot+bluetooth
2 siblings, 0 replies; 4+ messages in thread
From: bluez.test.bot @ 2023-03-06 9:35 UTC (permalink / raw)
To: linux-bluetooth, apusaka
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off
2023-03-06 9:07 [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off Archie Pusaka
2023-03-06 9:35 ` bluez.test.bot
@ 2023-03-06 12:44 ` Simon Horman
2023-03-07 18:40 ` patchwork-bot+bluetooth
2 siblings, 0 replies; 4+ messages in thread
From: Simon Horman @ 2023-03-06 12:44 UTC (permalink / raw)
To: Archie Pusaka
Cc: linux-bluetooth, Luiz Augusto von Dentz, Marcel Holtmann,
CrosBT Upstreaming, Archie Pusaka, Abhishek Pandit-Subedi,
David S. Miller, Eric Dumazet, Jakub Kicinski, Johan Hedberg,
Paolo Abeni, linux-kernel, netdev
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off
2023-03-06 9:07 [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off Archie Pusaka
2023-03-06 9:35 ` bluez.test.bot
2023-03-06 12:44 ` [PATCH] " Simon Horman
@ 2023-03-07 18:40 ` patchwork-bot+bluetooth
2 siblings, 0 replies; 4+ messages in thread
From: patchwork-bot+bluetooth @ 2023-03-07 18:40 UTC (permalink / raw)
To: Archie Pusaka
Cc: linux-bluetooth, luiz.dentz, marcel,
chromeos-bluetooth-upstreaming, apusaka, abhishekpandit, davem,
edumazet, kuba, johan.hedberg, pabeni, linux-kernel, netdev
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!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-03-07 18:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-06 9:07 [PATCH] Bluetooth: hci_sync: Don't wait peer's reply when powering off Archie Pusaka
2023-03-06 9:35 ` bluez.test.bot
2023-03-06 12:44 ` [PATCH] " Simon Horman
2023-03-07 18:40 ` patchwork-bot+bluetooth
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.