up_rtc_gettime: add spinlock to protect up_rtc_gettime

[hujun260]

Summary

up_rtc_gettime: add spinlock to protect up_rtc_gettime

Impact

up_rtc_gettime

Testing

ci

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides a summary of the change, it lacks crucial details. Here's a breakdown:

Missing Information:

• Summary: While the title mentions adding a spinlock, the why is missing. What race condition or problem does this fix? Which part of the code is changed (the specific function is mentioned, but a more general area like "RTC driver" would be helpful)? How does the spinlock solve the problem? Issue numbers are missing.
• Impact: The impact section is severely lacking. It just repeats the function name. All the YES/NO questions need to be answered with explanations. Does this change affect any particular architectures, boards, or drivers? Does it change the API? Does it require documentation updates? Are there security implications of adding this lock?
• Testing: "ci" is insufficient. What specific targets were tested? What tests were run? Actual log output (or a link to it) demonstrating the problem before the change and the successful operation after the change is needed. Host build environment information is also missing.

Example of how to improve the Summary:

"The up_rtc_gettime function was prone to race conditions when accessed concurrently from multiple threads, potentially leading to incorrect time readings. This change adds a spinlock to protect access to the RTC hardware during the up_rtc_gettime operation within the common RTC driver code. This fixes [Issue #XYZ]. This change also affects the up_rtc_settime function, which now also acquires the same spinlock.

Example of how to improve the Impact:

• Is new feature added? NO
• Is existing feature changed? YES, the up_rtc_gettime and up_rtc_settime functions are now thread-safe.
• Impact on user (will user need to adapt to change)? NO
• Impact on build (will build process change)? NO
• Impact on hardware (will arch(s) / board(s) / driver(s) change)? NO. This change is within the common RTC driver code, so all architectures using this driver benefit.
• Impact on documentation (is update required / provided)? YES, the documentation for up_rtc_gettime and up_rtc_settime should mention the thread-safety improvements. A documentation update is included in this PR.
• Impact on security (any sort of implications)? NO
• Impact on compatibility (backward/forward/interoperability)? NO
• Anything else to consider? The addition of the spinlock introduces a small performance overhead.

Example of how to improve the Testing:

• Build Host(s): Linux (Ubuntu 20.04), x86_64, GCC 9.4.0
• Target(s): sim:qemu-arm, stm32f4discovery:nsh

Testing logs before change: (demonstrate the race condition - e.g., inconsistent time readings from two threads accessing the RTC simultaneously)

... log output showing the problem ...

Testing logs after change: (show consistent time readings and no errors)

... log output showing the fix ...

Or:
Testing logs are available in the CI run for this PR: [Link to CI run]

By providing this level of detail, reviewers can quickly understand the change, its impact, and verify its correctness, leading to a faster and smoother review process.