On Fri, Apr 17, 2020 at 6:26 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > How about in the commit hooks? >
Yes, we can add pre-commit script to tools folder, but developer still need to copy the hook into .git/hooks folder manually. And we also need enable all same check on github/apache server as the last quality guard. > -----Original Message----- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Thursday, April 16, 2020 7:47 PM > To: dev@nuttx.apache.org > Subject: Re: Adding support for STM32G474RET6 > > On Fri, Apr 17, 2020 at 5:54 AM David Sidrane <david.sidr...@nscdg.com> > wrote: > > > > Thank you for fixing the typos. I am sure I can make them faster than you > > can fix them. :) > > > > Actually, checkpatch.sh support -c option which do the spell check by > invoke codespell(the same tool used by Linux): > https://github.com/codespell-project/codespell > How about we enable -c option in github check action? > > > > > I started to lean heavier on the side of Kconfig. You should know > > historically, there was a pre Kconfig time, so this is an organic > > trajectory. > > > > The dividing lines for me are invariant vs variant and user selectable vs > > chip selected. > > > > For KINETIS_PMC_VERSION_05 - the context is fixed in terms of the chips, > > we > > are not building chips in Kconfig - that would hurt, it would also not be > > as > > clear, the h file is richer than the Kconfig files comments wise. > > > > While looking at the part number breakdown for the F3's and having to add > > a > > chip that had only a different size Flash drove the > > STM32H7_FLASH_CONFIG_x - > > That seemed like and easy win and one a user could benefit from. > > > > David > > > > -----Original Message----- > > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > > Sent: Thursday, April 16, 2020 12:39 PM > > To: dev@nuttx.apache.org > > Subject: Re: Adding support for STM32G474RET6 > > > > On Thu, Apr 16, 2020 at 1:00 PM David Sidrane <david.sidr...@nscdg.com> > > wrote: > > > If you look at the Kinetis, > > > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 > > > > > > You can see the gist of that approach. > > > > > > It idea was as developers on the outside of the MFG, we only see the > > > deltas > > > in datasheets. We do not know, the feature set that was added to add to > > > the > > > silicon. > > > So if the IP versioning is not described by the MFG we can make up > > > names. > > > > > > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 > > > > > > Then add the "HAS"s. To a feature set or chip and have reuse at the chip > > > level and not litter the code with partnumber. > > > > Thanks. I looked at that... > > > > I'd like to ask: It seems that some decisions are made in Kconfig > > logic using hidden configs, e.g., > > > > select KINETIS_HAVE_LPUART0, or > > select STM32H7_FLASH_CONFIG_I > > > > while other decisions are made in code, e.g., > > > > #if defined(CONFIG_ARCH_CHIP_MK28FN2M0VMI15) > > #define KINETIS_PMC_VERSION KINETIS_PMC_VERSION_05 > > > > Is there a policy or rule of thumb as to when MCU-specific stuff is > > decided in Kconfig and when it's decided in code? > > > > Thanks, > > Nathan > > > > P.S., I couldn't help myself, if I see a typo, I have to fix it, or I > > don't sleep well at night. :-)
