Skip to content

Conversation

@BluezTestBot
Copy link
Owner

If there are already flags that are pending to be applied, we should
keep them to avoid overwriting them.
At that point we only want to add the Device Privacy Mode on top of the
existing flags.

src/adapter.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

tedd-an and others added 4 commits March 24, 2025 16:46
This patch adds workflow files for ci:

[sync.yml]
  - runs every 30 mins.
  - sync repo with upstream repo and rebase workflow branch to tip of
    master.
  - creates PR after reading patches from patchwork.kernel.org

[ci.yml]
  - Tests the following checks:
    - checkpatch
    - gitlint
    - make
    - make check

[code_scan.yml]
    - Static code checker: Coverity and Clang
    - Coverity: Submit the result to the coverity website
    - Clang Code Scan: Send email with result file to the internal team

To simplify the history, new change will amend to this patch without
creating new patch.
If there are already flags that are pending to be applied, we should
keep them to avoid overwriting them.
At that point we only want to add the Device Privacy Mode on top of the
existing flags.
If there are already flags that are pending to be applied, we should
keep them to avoid overwriting them.
In device_set_wake_allowed() we only want to either add or remove the
remote wakeup flag, while keeping the existing flags as-is.
When the function `device_set_wake_support()` is called, we don't have
the guarantees for the device to be already bonded.

For example, that function gets called by `hog_probe()`, that is also
triggered when bluez scans for new devices. In that instance, we don't
want to try setting the `wake_allowed` property, because those devices
are only in range of the host and are not connected, paired or bonded
yet.

This fixes the following Bluez error when we scan for new devices and a
new hog or hid is in range:
```
src/device.c:set_wake_allowed_complete() Set device flags return status:
Invalid Parameters
```

Additionally, because that initial `device_set_allowed()` call can fail,
this commit fixes the issue of hog and hid devices that, after the first
pairing, were unexpectedly showing `WakeAllowed: no`. And it required a
reboot to let that property be set to the expected `WakeAllowed: yes` by
default.
@BluezTestBot
Copy link
Owner Author

CheckPatch
Desc: Run checkpatch.pl script
Duration: 0.24 seconds
Result: PENDING

@BluezTestBot
Copy link
Owner Author

GitLint
Desc: Run gitlint
Duration: 0.22 seconds
Result: PENDING

@BluezTestBot
Copy link
Owner Author

BuildEll
Desc: Build and Install ELL
Duration: 20.76 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

BluezMake
Desc: Build BlueZ
Duration: 1503.05 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

MakeCheck
Desc: Run Bluez Make Check
Duration: 13.63 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

MakeDistcheck
Desc: Run Bluez Make Distcheck
Duration: 171.29 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

CheckValgrind
Desc: Run Bluez Make Check with Valgrind
Duration: 225.50 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

CheckSmatch
Desc: Run smatch tool with source
Duration: 307.78 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

bluezmakeextell
Desc: Build Bluez with External ELL
Duration: 98.94 seconds
Result: PASS

@BluezTestBot
Copy link
Owner Author

IncrementalBuild
Desc: Incremental build with the patches in the series
Duration: 0.32 seconds
Result: PENDING

@BluezTestBot
Copy link
Owner Author

ScanBuild
Desc: Run Scan Build
Duration: 876.53 seconds
Result: PASS

@github-actions github-actions bot force-pushed the workflow branch 8 times, most recently from a6c8b9c to d9941ad Compare April 2, 2025 10:43
@github-actions github-actions bot force-pushed the workflow branch 5 times, most recently from a65fdba to 89a49a5 Compare April 9, 2025 20:41
@github-actions github-actions bot force-pushed the workflow branch 2 times, most recently from 47d52e0 to df874a4 Compare April 18, 2025 14:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants