| Message ID | 20201217150346.1.If6feff48e17a881af9cb55526db7f53bf0db40f1@changeid (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | Bluetooth: Pause service discovery for suspend | expand |
| Context | Check | Description |
|---|---|---|
| netdev/cover_letter | success | Link |
| netdev/fixes_present | success | Link |
| netdev/patch_count | success | Link |
| netdev/tree_selection | success | Guessed tree name to be net-next |
| netdev/subject_prefix | warning | Target tree name not specified in the subject |
| netdev/source_inline | success | Was 0 now: 0 |
| netdev/verify_signedoff | success | Link |
| netdev/module_param | success | Was 0 now: 0 |
| netdev/build_32bit | success | Errors and warnings before: 2 this patch: 2 |
| netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
| netdev/verify_fixes | success | Link |
| netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 14 lines checked |
| netdev/build_allmodconfig_warn | success | Errors and warnings before: 2 this patch: 2 |
| netdev/header_inline | success | Link |
| netdev/stable | success | Stable not CCed |
Hi Abhishek, > Just like MGMT_OP_START_DISCOVERY, we should reject > MGMT_OP_START_SERVICE_DISCOVERY with MGMT_STATUS_BUSY when we are paused > for suspend. > > Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> > --- > On ChromeOS, we started getting reports of scanning failing after > resuming from suspend. The root cause was that Start Service Discovery > was being called while discovery was supposed to be paused for suspend > and it was screwing up some internal state. Adding this check > immediately fixed it. > > The fix was tested by doing the following: > * Set Discovery Filter ({'transport': 'auto'}) > * Start Discovery > * Suspend > * Resume > * Check the Discovering property > > Without the fix, this test failed when checking the Discovering > property above. > > net/bluetooth/mgmt.c | 8 ++++++++ > 1 file changed, 8 insertions(+) patch has been applied to bluetooth-next tree. Regards Marcel
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index fa0f7a4a1d2fc8a..608dda5403b7327 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -4798,6 +4798,14 @@ static int start_service_discovery(struct sock *sk, struct hci_dev *hdev, goto failed; } + if (hdev->discovery_paused) { + err = mgmt_cmd_complete(sk, hdev->id, + MGMT_OP_START_SERVICE_DISCOVERY, + MGMT_STATUS_BUSY, &cp->type, + sizeof(cp->type)); + goto failed; + } + uuid_count = __le16_to_cpu(cp->uuid_count); if (uuid_count > max_uuid_count) { bt_dev_err(hdev, "service_discovery: too big uuid_count value %u",
Just like MGMT_OP_START_DISCOVERY, we should reject MGMT_OP_START_SERVICE_DISCOVERY with MGMT_STATUS_BUSY when we are paused for suspend. Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> --- On ChromeOS, we started getting reports of scanning failing after resuming from suspend. The root cause was that Start Service Discovery was being called while discovery was supposed to be paused for suspend and it was screwing up some internal state. Adding this check immediately fixed it. The fix was tested by doing the following: * Set Discovery Filter ({'transport': 'auto'}) * Start Discovery * Suspend * Resume * Check the Discovering property Without the fix, this test failed when checking the Discovering property above. net/bluetooth/mgmt.c | 8 ++++++++ 1 file changed, 8 insertions(+)