Hi Marcel,
After further automated testing of the upstreamed suspend patches,
I found two issues:
- A failure in PM_SUSPEND_PREPARE wasn't calling PM_POST_SUSPEND.
I misread the docs and thought it would call it for all notifiers
already run but it only does so for the ones that returned
successfully from PM_SUSPEND_PREPARE.
- hci_conn_complete_evt wasn't completing on auto-connects (an else
block was removed during a refactor incorrectly)
With the following patches, I've run a suspend stress test on a couple
of Chromebooks for several dozen iterations (each) successfully.
Thanks
Abhishek
Abhishek Pandit-Subedi (2):
Bluetooth: Restore running state if suspend fails
Bluetooth: Fix incorrect branch in connection complete
net/bluetooth/hci_core.c | 39 ++++++++++++++++++++-------------------
net/bluetooth/hci_event.c | 17 +++++++++--------
2 files changed, 29 insertions(+), 27 deletions(-)
--
2.25.1.696.g5e7596f4ac-goog
When handling auto-connected devices, we should execute the rest of the
connection complete when it was previously discovered and it is an ACL
connection.
Signed-off-by: Abhishek Pandit-Subedi <[email protected]>
---
net/bluetooth/hci_event.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 20408d386268..cd3d7d90029b 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2539,16 +2539,17 @@ static void hci_conn_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
bt_dev_err(hdev, "no memory for new conn");
goto unlock;
}
- }
-
- if (ev->link_type != SCO_LINK)
- goto unlock;
+ } else {
+ if (ev->link_type != SCO_LINK)
+ goto unlock;
- conn = hci_conn_hash_lookup_ba(hdev, ESCO_LINK, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ conn = hci_conn_hash_lookup_ba(hdev, ESCO_LINK,
+ &ev->bdaddr);
+ if (!conn)
+ goto unlock;
- conn->type = SCO_LINK;
+ conn->type = SCO_LINK;
+ }
}
if (!ev->status) {
--
2.25.1.696.g5e7596f4ac-goog
Hi Abhishek,
> After further automated testing of the upstreamed suspend patches,
> I found two issues:
> - A failure in PM_SUSPEND_PREPARE wasn't calling PM_POST_SUSPEND.
> I misread the docs and thought it would call it for all notifiers
> already run but it only does so for the ones that returned
> successfully from PM_SUSPEND_PREPARE.
> - hci_conn_complete_evt wasn't completing on auto-connects (an else
> block was removed during a refactor incorrectly)
>
> With the following patches, I've run a suspend stress test on a couple
> of Chromebooks for several dozen iterations (each) successfully.
>
> Thanks
> Abhishek
>
>
>
> Abhishek Pandit-Subedi (2):
> Bluetooth: Restore running state if suspend fails
> Bluetooth: Fix incorrect branch in connection complete
>
> net/bluetooth/hci_core.c | 39 ++++++++++++++++++++-------------------
> net/bluetooth/hci_event.c | 17 +++++++++--------
> 2 files changed, 29 insertions(+), 27 deletions(-)
both patches have been applied to bluetooth-next tree.
Regards
Marcel
Thanks Marcel.
On Mon, Mar 23, 2020 at 10:50 AM Marcel Holtmann <[email protected]> wrote:
>
> Hi Abhishek,
>
> > After further automated testing of the upstreamed suspend patches,
> > I found two issues:
> > - A failure in PM_SUSPEND_PREPARE wasn't calling PM_POST_SUSPEND.
> > I misread the docs and thought it would call it for all notifiers
> > already run but it only does so for the ones that returned
> > successfully from PM_SUSPEND_PREPARE.
> > - hci_conn_complete_evt wasn't completing on auto-connects (an else
> > block was removed during a refactor incorrectly)
> >
> > With the following patches, I've run a suspend stress test on a couple
> > of Chromebooks for several dozen iterations (each) successfully.
> >
> > Thanks
> > Abhishek
> >
> >
> >
> > Abhishek Pandit-Subedi (2):
> > Bluetooth: Restore running state if suspend fails
> > Bluetooth: Fix incorrect branch in connection complete
> >
> > net/bluetooth/hci_core.c | 39 ++++++++++++++++++++-------------------
> > net/bluetooth/hci_event.c | 17 +++++++++--------
> > 2 files changed, 29 insertions(+), 27 deletions(-)
>
> both patches have been applied to bluetooth-next tree.
>
> Regards
>
> Marcel
>