-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Bluetooth: Controller: Fix device address in Periodic Adv Sync #84908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth: Controller: Fix device address in Periodic Adv Sync #84908
Conversation
8d95a5b
to
076d213
Compare
151b8b4
to
be90e62
Compare
@Tronil FYI, a bug reported by @jakkra in a private devzone.nordicsemi.com ticket. A draft nRF Connect SDK v2.2.0 backport pull requests here: nrfconnect/sdk-nrf#20142 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the TODO here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated comment.
Fix incorrect device address reported in the LE Periodic Advertising Sync Established event when using Periodic Advertiser List. During Extended Scanning there can be an ADV_EXT_IND PDU received between currently being received ADV_EXT_IND PDU and AUX_ADV_IND PDU; if the one received between has an address match then incorrectly the Periodic Synchronization was established to the device whos AUX_ADV_IND PDU is being received. Fix by storing the auxiliary context that has the address match and compare with it when matching the SID in SyncInfo of AUX_ADV_IND PDU being received prior to creating the synchronization. Signed-off-by: Vinayak Kariappa Chettimada <[email protected]>
be90e62
to
7c351a5
Compare
* TODO: As the previous design has Bluetooth Qualified Design Listing by | ||
* Nordic Semiconductor ASA, both implementation are present in this file, | ||
* and default builds use CONFIG_BT_CTLR_SCAN_AUX_USE_CHAINS=n. Remove old | ||
* implementation when we have a new Bluetooth Qualified Design Listing | ||
* with the new Extended Scanning and Periodic Sync implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless there are any specific plans to qualify the Zephyr controller again by anyone, I think we can just remove the old implementation right? The existing qualification is for a much older version of Zephyr, and cannot be used with this version anyhow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless there are any specific plans to qualify the Zephyr controller again by anyone, I think we can just remove the old implementation right?
We do not have information about users of the Zephyr Controller doing/planning qualified end product listing of their downstream fork applications.
The existing qualification is for a much older version of Zephyr, and cannot be used with this version anyhow
Qualified design listing applies to a design and as long as the design remains same for the said finite feature set (ICS), newer versions of the implementation tested using the same test plan are listed under the same listing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get your point, but I still feel like this TODO is out of place. We are modifying existing features in both the host and controller all the time, and using a design listing for Zephyr 2.3 with Zephyr 4.0 would, even without removing this specific old implementation, likely not go well. The design listing is specifically for 2.2 and 2.3, so I don't think we need to care about that for 4.1 and future releases.
We do not have information about users of the Zephyr Controller doing/planning qualified end product listing of their downstream fork applications.
Then that's up to them. We can deprecate the old implementation by following the deprecation process in Zephyr, and then it will be up to downstream forks to determine whether they want to follow this, fork, or revert the removal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The design listing is specifically for 2.2 and 2.3, so I don't think we need to care about that for 4.1 and future releases.
"The Zephyr™ Controller subsystem was qualified with QDID 150092 for nRF52833 and nRF Connect SDK 1.3.2 for core specification 5.1. Other qualifications for the Zephyr Controller subsystem are not planned."
This is a revision in the Zephyr v3.x release (v3.2.99) leading to the v3.7.0 LTS. We do not deprecate a design and go back to experimental as default, but deprecate a design when there is equivalent qualified design as default replacing it.
Example, #49573
@Tronil Do we know a newer design listing with the chain implementation, and shall we switch the default design upstream?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know a newer design listing with the chain implementation, and shall we switch the default design upstream?
I don't know of one (but I really only know what we have qualified here downstream). I can say that we regularly run EBQ on our downstream version that uses the new design and haven't had any failures.
In my opinion we can switch the default - I don't know what the usual procedure is wrt. qualifications and deprecations though, so I'll refrain from having an opinion on that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jakkra FYI.
Fix incorrect device address reported in the LE Periodic Advertising Sync Established event when using Periodic Advertiser List.