rt-thread.git/src/cpu_mp.c, branch copilot/update-elm-fatfs-to-r016

doxygen: fixed duplicated comments for cpu APIs

2025-09-08T14:20:52Z

Refer to the issue described in PR #10599. This was a temporary fix at that time. After further research, we discovered that this issue can be addressed using the "@cond" command supported by Doxygen. Since we currently do not intend to generate two sets of documentation for UP and MP when generating Doxygen documentation, the current solution is to generate only MP documentation by default. For functions defined in MP but not in UP, we will use the "@note" command in the function's Doxygen comment to indicate whether the function supports both UP and MP, or only MP. Signed-off-by: Chen Wang

doxygen: fix build error

2025-08-12T01:14:46Z

fixed: b084503b6d "[kernel] add UP scheduler critical switch flag." After this commit, doxygen build with warning: include/rtthread.h:658: warning: argument 'lock' from the argument list of rt_spin_unlock has multiple @param documentation sections include/rtthread.h:660: warning: argument 'lock' from the argument list of rt_spin_unlock_irqrestore has multiple @param documentation sections include/rtthread.h:660: warning: argument 'level' from the argument list of rt_spin_unlock_irqrestore has multiple @param documentation sections Rootcasue analysis: src/cpu_up.c and src/cpu_mp.c define two identical functions. Because the INPUT parameter in the documentation/Doxyfile currently compiles all source files under ./src, i.e both of them, Doxygen automatically merges the Doxygen comments for identically named functions if it finds the content of doxygen comments different, resulting in multiple @param. Previously, the API comments in both files were identical, so there was no problem. However, the b084503b6d change only modified the comments in src/cpu_up.c but not in src/cpu_mp.c, causing problems. Another drawback of the b084503b6d change is that Doxygen recommends a single line for the @brief; multiple lines are not recommended. Solution: Given the requirement for a single line for the @brief, this issue is relatively simple to resolve: simply list the extra content as @note. Regarding the warning: A perfect solution has not yet been found. One possible approach is to write a single Doxygen comment for a kernel API with two implementations. This approach involves writing Doxygen comments in only one file, such as src/cpu_up.c , while omitting them in src/cpu_mp.c . Another solution is to add API comments to include/rtthread.h , but the RT-Thread include/rtthread.h file is already quite large, and adding comments there would be even more cumbersome. A temporary solution currently in use is to ensure that the Doxygen comments for the same API are identical in both src/cpu_up.c and src/cpu_mp.c . This ensures that Doxygen compilation does not generate warnings, and the files are automatically merged into a single file in the HTML document. Signed-off-by: Chen Wang

[libcpu/arm64] add C11 atomic ticket spinlock (#8882)

2024-05-16T07:45:12Z

* [libcpu/arm64] add C11 atomic ticket spinlock Replace the former implementation of flag-based spinlock which is unfair Besides, C11 atomic implementation is more readable (it's C anyway), and maintainable. Cause toolchain can use their builtin optimization and tune for different micro-architectures. For example armv8.5 introduces a better instruction. The compiler can help with that when it knows your target platform in support of it. Signed-off-by: Shell * fixup: RT_CPUS_NR --------- Signed-off-by: Shell

[hrtimer] fixup use-after-free (#8928)

2024-05-11T00:53:42Z

Signed-off-by: Shell

[src] add rt_hw_cpu_id() wrapper API (#8894)

2024-05-08T01:22:09Z

* [src] add rt_hw_cpu_id() wrapper API rt_hw_cpu_id() is an unsafe API which should not be used by most codes directly. It's error-prone because it must be used in proper context, otherwise it can lead to errors and unpredictable behavior. This patch adds a wrapper API for rt_hw_cpu_id() to address this risk. It includes the context-checking functionality and provides a safer alternative for obtaining CPU IDs, ensuring that it is used correctly within the appropriate context. Signed-off-by: Shell * fixup UMP * update API & comment * ci: cpp_check --------- Signed-off-by: Shell

fixup: debug

2024-04-20T01:30:12Z

add cpu up

2024-04-20T01:30:12Z