Use small lock to protect usbdev and endpoint in arch ARM.

[wangzhi-art]

Note: Please adhere to Contributing Guidelines.

Summary

Use small lock to protect usbdev and endpoint in arch ARM.

Impact

arch/arm/src/cxd56xx/cxd56_usbdev.c
arch/arm/src/dm320/dm320_usbdev.c
arch/arm/src/efm32/efm32_usbdev.c
arch/arm/src/imxrt/imxrt_usbdev.c
arch/arm/src/kinetis/kinetis_usbdev.c
arch/arm/src/lpc17xx_40xx/lpc17_40_usbdev.c
arch/arm/src/lpc214x/lpc214x_usbdev.c
arch/arm/src/lpc31xx/lpc31_usbdev.c
arch/arm/src/rp2040/rp2040_usbdev.c
arch/arm/src/rp23xx/rp23xx_usbdev.c
arch/arm/src/samv7/sam_usbdevhs.c
arch/arm/src/stm32/stm32_usbdev.c
arch/arm/src/stm32f0l0g0/stm32_usbdev.c
arch/arm/src/stm32l4/stm32l4_usbdev.c
include/nuttx/usb/usbdev.h

Testing

CI

[nuttxpr]

[Experimental Bot, please feedback here]

This PR appears to mostly meet the NuttX requirements, but is lacking some crucial information. Here's a breakdown:

Strengths:

• Clear Summary of Changes: The summary clearly states the what and how of the change. Using a small lock to protect shared resources is a good practice.
• Specific File List: Listing the impacted files is extremely helpful for reviewers.
• Mentions CI: Indicating that Continuous Integration (CI) testing will be performed is good.

Weaknesses:

• Missing "Why": The summary lacks the crucial why. Why is this lock necessary? Is there a bug being fixed? Is this a performance optimization? A race condition being prevented? This is the most important part of the summary. Reference a specific NuttX issue number if one exists.
• Impact Section Incomplete: While the file list gives a technical impact, the Impact section is missing the user impact descriptions. The PR author assumes NO impact across the board, which is unlikely. Even internal changes can have indirect effects. Think carefully about each point. For example:
  • Impact on Build: Will adding locks increase code size? Will it change any build dependencies?
  • Impact on Hardware: Will the use of locks affect real-time performance on any particular architectures?
  • Impact on Security: Does this change mitigate any potential vulnerabilities related to concurrent access to USB resources? If so, be explicit.
• Testing Section Severely Lacking: Just saying "CI" isn't sufficient. While CI is important, local testing is crucial. The PR needs to demonstrate that the change actually works and fixes the intended problem (which is currently undefined). Provide specific test cases and their before and after logs. What platforms did you test on? Be explicit (e.g., "Build Host: Linux, x86_64, GCC 11.2. Target: STM32F4 Discovery board"). If it's a bug fix, show how the bug manifested before and how it's resolved after. If a performance improvement, provide benchmarks.

Recommendations for Improvement:

1. Explain the "Why": Provide a concise explanation of the problem this PR solves. Is it a bug fix? Performance improvement? Preemptive fix for a potential issue? Link to a NuttX issue if one exists.
2. Complete the Impact Section: Address each point, even if the answer is "NO." If "NO," briefly justify why there's no impact. If "YES," provide specific details.
3. Provide Detailed Testing Information: Include specific test cases, platforms tested (host and target), and before and after logs demonstrating the effect of the change. Don't just rely on CI.

By addressing these weaknesses, the PR will be much stronger and easier for reviewers to evaluate. A good PR saves everyone time and leads to a higher quality codebase.