Thank you Kerogit :-) How about ARCH_HAVE_AVR_FLMAP? This would align with existing nomenclature and enable easy filtering / sorting?
Thanks :-) Tomek On Tue, Jul 8, 2025 at 11:29 PM <kr....@kerogit.eu> wrote: > > Hello, > > I prepared new version of the series, it's available in branch named > avrdx_flmap_v2 (and also attached.) > > The changes are based on the feedback both from the mailing list and > from PR: > > 1) the #endif alignment was fixed. Checkpatch doesn't complain about > assembly files unfortunately and I missed this one as well. > > 2) since no one was happy with the naming of the new configuration > options, they are renamed to what xiaoxiang781216 suggested, ie. > > - AVR_HAVE_FLMAP to denote chip with memory-mapping support > - AVR_HAVE_BOARD_FLMAP to denote board with linker script that responds > to configuration values set by the user > > I did not rename AVR_HAS_RAMPZ for the time being, the patch series > would then affect AtMega family as well. Now it only affects AVR DA/DB > and I don't want to broaden the scope. > > As for the HAVE/HAS discussion on GitHub, I think it depends on the view > of the speaker - AVR (architecture - singular) has but AVR (chips - > plural) have. I am not native speaker though. > > I have been using AVR_HAS_something for configuration options because it > matches AVR_HAS_MEMX_PTR which was present in the code before I started > working on it (as opposed to - unless I missed something - no > AVR_HAVE_something.) If AVR_HAVE is preferable for new code, I don't > have any problem with that but I would rather avoid renaming the > existing options to prevent needless (IMO) code churn. > > Feel free to let me know if there's something else to work out. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
