Why not keep it here ? It doesn't seem to hurt and could maybe be renamed mips32r2 to be inline with the provided feature. All this could be factorized by the way (the same as for FEATURES_PROVIDED += cpu_$(CPU) and keep in-sync with Kconfig until we are done with Kconfig.

Why not keep it here ?

Well I think that moving this to the common place makes sense. We are already including mips32r2_common/Makefile.features so it made sense to me that all who include that inherit the CPU_ARCH value.

All this could be factorized by the way

Sorry, I did not get this. How would it look like?

Here:

We could add:

FEATURES_PROVIDED += cpu_arch_$(CPU_ARCH)

And maybe add similar things for CPU_CORE, CPU_FAM. This way it becomes easy to filter features based on finer grained information because for the moment we only have ARCH (arch_32bit, arch_avr, etc) but no intermediate.

And that be in sync with what Kconfig is exposing: HAS_CPU_CORE_STM32, etc

I see. But Kconfig is not providing this information as features (i.e. HAS_ prefixed symbols). It only has the symbols CPU_ARCH_, CPU_CORE_... If we start adding this as features then we need to duplicate this information in Kconfig by adding symbols like HAS_CPU_ARCH_ for every level of the hierarchy

Ok, I see. Thanks for the clarification. So then that's ok for the moment to remove it here I guess.