Bluetooth: Controller: nrf54lx: Fix address resolution wait

[cvinayak]

Fix address resolution wait to not be infinite loop and instead exit with a reasonable count down value.

Fixes #100101

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

This PR fixes an infinite loop issue in address resolution waiting logic for the nRF54LX Bluetooth controller by introducing a countdown-based timeout mechanism. The fix addresses issue #100101 where the code could hang indefinitely waiting for address resolution to complete.

Key Changes:

• Introduces a new ar_end_wait() helper function with a countdown timeout (200 iterations) to replace infinite wait loops
• Conditionally disables cpu_sleep() calls for NRF54LX SoC during the wait

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Copilot]

The conditional compilation check uses CONFIG_SOC_SERIES_NRF54LX, but throughout the rest of this file, the consistent pattern is to use CONFIG_SOC_COMPATIBLE_NRF54LX (as seen in lines 2645, 2689, 2709, 2711, 2771, 2787, etc.). This inconsistency could lead to incorrect behavior where cpu_sleep() is called (or not called) on the wrong platforms.

Suggested fix:

#if !defined(CONFIG_SOC_COMPATIBLE_NRF54LX)
	/* We do not sleep on target SoC. */
	cpu_sleep();
#endif /* !CONFIG_SOC_COMPATIBLE_NRF54LX */

Suggested change

	#if !defined(CONFIG_SOC_SERIES_NRF54LX)
	/* We do not sleep on target SoC. */
	cpu_sleep();
	#endif /* !CONFIG_SOC_SERIES_NRF54LX */
	#if !defined(CONFIG_SOC_COMPATIBLE_NRF54LX)
	/* We do not sleep on target SoC. */
	cpu_sleep();
	#endif /* !CONFIG_SOC_COMPATIBLE_NRF54LX */

[Copilot]

The magic number 200U for the countdown is arbitrary and lacks proper justification. While the comment mentions it "seems sufficient testing on target with one IRK to resolve," this doesn't provide guidance for:

1. What happens if multiple IRKs need to be resolved
2. How this value scales with different hardware configurations
3. Whether timeout detection/handling is needed when countdown reaches 0

Consider either:

• Defining this as a named constant (e.g., #define AAR_WAIT_COUNTDOWN_MAX 200U) with documentation explaining the expected timing
• Adding timeout error handling/logging when countdown reaches 0
• Documenting the expected maximum duration based on hardware specifications

[Copilot]

Grammatical error: "be not be waiting" should be "not be waiting".

Suggested change

	* We should ideally be not be waiting anyway, and in theory be resolved before we are here.
	* We should ideally not be waiting anyway, and in theory be resolved before we are here.

[Copilot]

Missing error handling or status return when the countdown expires. If NRF_AAR->EVENTS_END remains 0 after the countdown completes, the calling code has no way to detect this timeout condition. This could mask hardware issues or unexpected delays.

Consider:

• Returning a status code from ar_end_wait() to indicate success/timeout
• Adding an assertion or error log when the timeout occurs
• Documenting the expected behavior when timeout happens