Hi Alan, Matteo, Thanks for the feedback. I understand the concern about introducing another external HAL dependency. For Renesas, reusing the FSP HAL is part of our long-term support strategy. The goal is not only to reduce the initial development effort, but also to keep the low-level drivers aligned with vendor fixes, new device support and future FSP releases. Maintaining a separate native NuttX implementation would duplicate the drivers and require an independent long-term maintenance effort. Would a Zephyr-like repository model be more acceptable? The idea would be to host the HAL repository under the NuttX organization as the single source of truth, not as a downstream fork: - Anyone can contribute through pull requests. - The HAL's code owners maintain the HAL, review changes and synchronize upstream updates. - NuttX committers review the NuttX integration code. - HAL repository changes require approval from the code owners. - Merge rights, CODEOWNERS, CI and branch-protection rules are documented. This would give NuttX more governance over the dependency while keeping the HAL aligned with the vendor-supported FSP implementation. Would this model address the main concerns? If not, what additional conditions would be required for it to be feasible?
Best Regards, Binh Nguyen
