Hi All, I also think that keeping a vendor hal under github/NuttX is the best solution. I consider a vendor wishing to add a hal is a sign that they want to support NuttX and enable fast introduction of new devices.
When a hal is placed under github/NuttX it is under final control of NuttX PMC and Committers. It would be best to have this hal vendor maintained (and assign a vendor committer). An agreement (next to correct licensing of course) regarding handling of NuttX users created PR on the vendor hal should be in place: 1. A PR is assigned to the vendor committer, 2. An assigned PR needs to be handled in a timely manner (e.g. within a week), 3. When a PR is considered in "contradiction" with the vendor comitter an alternative should be proposed by the committer, 4. In cases where there is no resolution for 3. the NuttX PMC steps in and decides on the way forward, Respecting this agreement would result in NuttX PMC and Committers never having to merge code to the vendor hal. But when things go really bad (hope this never happens) the NuttX PMC and Committers can decide to reassign the hal committer. To keep the code in NuttX and vendor hal in sync the "dynamic" method as used by espressif can be used, where the build system is using a specific commit to checkout the hal. This avoids unneeded code checkout for NuttX users that are not using the hal and makes sure that older releases are using the correct hal version. This also makes it workable for the release team. For the NuttX code itself there is no obligation to use the provided vendor hal, if device support can be written without the use of the vendor hal this should still remain possible and this always is the preferred option. Best Regards, Jehudi Op vr 25 sep 2026 om 14:00 schreef Alan C. Assis <[email protected]>: > > Hi Alin, > > I think Xiang, Greg and Binh are right to suggest keeping it at > github.com/NuttX > > Only NuttX's PMCs and Committers have write access to this repository, so I > don't think this is a concern. > > ASF wants to own everything, to have control and legal rights over > everything, but that is a vendor HAL. > > Similarly, ARM shouldn't give away its CMSIS-DSP ownership to ASF if we > decide to integrate it into a chip here. > > BR, > > Alan > > On Fri, Sep 25, 2026 at 3:24 AM Alin Jerpelea <[email protected]> wrote: > > > Hi Binh, > > > > unfortunately I tend to disagree with point 2 > > hosting outside ASF in my opinion is not an option from a supply chain and > > management perspective > > I think that from a manufacturer point of view will be more secure to have > > all components under ASF, maintained by committers and under project's by > > PMC > > ASF already provides the user management and the needed infrastructure for > > this git ensuring proper proper resources so that it does not become a > > concern. > > > > My suggestion is to try and speak with management so that they understand > > the long therm benefits of hosting the HAL under ASF > > > > Best regards > > Alin Jerpelea > > > > On Fri, Sep 25, 2026 at 8:07 AM Binh Nguyen <[email protected]> > > wrote: > > > > > Hi all, > > > > > > Thanks for keeping the discussion going, let me share my thoughts on the > > > open points. > > > > > > 1. License (Gregory's question): Renesas FSP is BSD 3-Clause, so it's > > > Apache-2.0 compatible, licensing shouldn't be the blocker here. For > > > reference Zephyr accepts the same kind of thing for their vendor HALs, > > e.g. > > > hal_stm32, hal_nxp etc are also BSD/Apache-2.0 style, hosted separately > > > from the core zephyr repo. > > > > > > 2. Hosting: Agree with Xiang here, not proposing an SGA to donate the > > code > > > to ASF, FSP stays Renesas-owned. What we want is just a repo under > > > github.com/NuttX, outside the ASF-governed tree, same idea as Zephyr > > > keeping vendor HAL modules in separate repos under their org instead of > > > inside zephyrproject-rtos/zephyr. Solves Gregory's ownership/donation > > > concern and still gives NuttX committers real access instead of us just > > > pointing at an external fork. > > > > > > 3. Code quality: to be specific about which part is which - the > > adaptation > > > layer (drivers interfaces, board/arch integration, Kconfig, build glue) > > > would follow NuttX coding style and pass NuttX CI like any other code, > > > that's what NuttX committers review. The FSP source itself we'd keep > > mostly > > > as-is, rewriting it to match NuttX style kind of defeats the point of > > > reusing it and just forks us from upstream. > > > > > > 4. Maintenance risk: I can't promise Renesas will maintain it forever, > > > companies change priorities, we've all seen that happen. What I can say > > is > > > if that happens, the repo and history stay on github.com/NuttX, > > community > > > keeps full access and can just keep maintaining it themselves, no vendor > > > lock-in on the repo itself. Not that different from what already happens > > > when someone abandons a board they contributed. > > > > > > 5. On native (Matteo's question): honestly the main reason we'd rather > > not > > > go full native is duplicated effort - we'd be rewriting driver logic that > > > already exists and is maintained in our HAL, which we also use for Zephyr > > > on the same board. Keeping two separate low-level implementations going > > > long term is a real cost for us, and errata/new device support would > > still > > > need tracking twice. > > > > > > Happy to provide any further detail needed to support a formal vote on > > > this. > > > > > > Best Regards, > > > Binh Nguyen > > > > > > > >
