mpfs/mpfs_rcc: Add stub driver for FPGA clock and reset controller

[pussuw]

Summary

This patch adds a driver framework to control individual FPGA reset and clock gates.

For FPGA devices, only the fabric (FIC0/FIC1/FIC3) clock and reset can be controlled, which affects the whole fabric / domain. This is problematic for obvious reasons.

For MSS peripherals, clocks and reset are controlled individually for each peripheral via MSS memory mapped registers (MPFS_SYSREG). To get the same capability for FPGA peripherals, the same controller needs to be fabricated on the FPGA.

However, the FPGA clock/reset controller is entirely user dependent, so a generic implementation is not possible. However, a generic driver is needed in order to build the current FPGA peripheral drivers. A stub implementation of the driver is provided in order to achieve this.

Impact

Only the MPFS target is impacted.
There is no app, documentation or build impact outside of MPFS scope.
If an FPGA reset controller is not used, the impact is none whatsoever.

Testing

Tested on downstream MPFS target board (not public)

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the basic NuttX requirements, but it could be improved. While it addresses the core sections, it lacks specific details in key areas, weakening its overall clarity and testability.

Here's a breakdown:

Strengths:

• Clear problem statement: The summary effectively explains the why behind the change.
• Technical explanation: The summary provides a reasonable explanation of the how.
• Impact assessment: The impact section identifies the affected area (MPFS) and acknowledges the conditional nature of the impact (only relevant if an FPGA reset controller is used).

Weaknesses:

• Missing Issue References: No related NuttX issues are linked, making it harder to track the context or related discussions.
• Vague Testing Information: "Tested on downstream MPFS target board (not public)" is insufficient. While the board might not be public, you can still provide more information. Architecture (e.g., RISC-V), specific configurations used, and especially relevant excerpts of logs (even if redacted for sensitive information) are crucial. Simply stating "works as intended" without evidence isn't convincing.
• Missing Specifics in Impact: While it mentions "no app, documentation, or build impact," it's better to explicitly state "NO" for each category as per the template. Also, the security and compatibility impacts are not addressed. Even if there is no impact, explicitly stating "NO" with a brief justification (e.g., "NO - This change is localized to the MPFS driver and does not introduce new security vulnerabilities.") reinforces the review process.
• Stub Implementation Detail: While mentioning a stub implementation is good, the PR description should briefly explain how the stub works and what functionality it provides (or intentionally omits). This helps reviewers understand the current state and potential future extensions.

Recommendations for Improvement:

• Add Issue References: If no issue exists, consider creating one to track the feature/fix.
• Provide Concrete Testing Details: Even if the board is private, specify the architecture, configuration, and crucial log excerpts (even redacted) to demonstrate the change's effect. Show how you tested. What specific tests did you run? What were the expected outcomes?
• Complete the Impact Assessment: Explicitly answer all questions with "NO" or "YES" and provide brief justifications, even if the answer is "NO."
• Elaborate on the Stub Implementation: Briefly explain how the stub functions and its limitations. This helps reviewers understand the current state and future development possibilities.

By addressing these weaknesses, the PR will be significantly stronger, easier to review, and more likely to be merged.

[lupyuen]

Please remember to sign-off with git commit -s. Thanks :-)

• d28f80b

[cederom]

Thank you @pussuw :-)