Bluetooth: Controller: Fix periodic advertising synchronization cancel and synchronization established synchronize #45696
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Current implementation of ll_sync_create_cancel does not allow to stop synchronization after ull_sync_setup is called. When that is done, sync->timeout_reload is not zero and the ll_sync_create_cancel will return BT_HCI_ERR_CMD_DISALLOWED. That means the Controller is able to cancel periodic advertising synchronization only in period between call to ll_sync_create and reception of AUX_ADV_IND that has SyncInfo field. The Controller should be able to cancell synchronization until first AUX_SYNC_IND PDU is received and host notified about synchronization established. Complete information about synchronization status is provdied by two ll_sync_set members: node_rx_sync_established and timeout_reload. These two members of the structure were used in ll_sync_create_cancel function to do a proper cancel and cleanup. The node_rx_sync_established member was not cleared when sync was established or expired. That was required to get a proper information about synchronization state. Besides that, to avoid race condition between ll_sync_create_cancel and ull_sync_established_report, the latter function was extended to check if cancel operation or sync lost has happened. Signed-off-by: Piotr Pryga <[email protected]>
ppryga-nordic
added
bug
ppryga-nordic
requested review from
carlescufi,
cvinayak,
thoh-ot and
kruithofa
as code owners
cvinayak
approved these changes
May 16, 2022
kruithofa
approved these changes
May 16, 2022
ppryga-nordic
deleted the
github-ble-fix-per-sync-canel-and-sync-establish-synchronization
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current implementation of ll_sync_create_cancel does not allow to stop
synchronization after ull_sync_setup is called. When that is done,
sync->timeout_reload is not zero and the ll_sync_create_cancel will
return BT_HCI_ERR_CMD_DISALLOWED. That means the Controller is able to
cancel periodic advertising synchronization only in period between
call to ll_sync_create and reception of AUX_ADV_IND that has SyncInfo
field.
The Controller should be able to cancell synchronization until first
AUX_SYNC_IND PDU is received and host notified about synchronization
established.
Complete information about synchronization status is provdied by two
ll_sync_set members: node_rx_sync_established and timeout_reload.
These two members of the structure were used in ll_sync_create_cancel
function to do a proper cancel and cleanup.
The node_rx_sync_established member was not cleared when sync was
established or expired. That was required to get a proper information
about synchronization state.
Besides that, to avoid race condition between ll_sync_create_cancel
and ull_sync_established_report, the latter function was extended
to check if cancel operation or sync lost has happened.
Fixes #40204 and #45672
Signed-off-by: Piotr Pryga [email protected]