On Thu, Jun 06, 2019 at 11:40:08AM +0000, Linder Pascal wrote:
Hi everyone,
I would like to turn on configurations for several Keymile boards, which are all using the Kirkwood architecture. Now, I do not want to change every defconfig file one after the other. Until now, we have used a common header file, but with the conversion to Kconfig another method has to be elaborated.
While searching in the U-Boot source code, I found two different manners to fulfill our needs:
- in arch/arm/mach-kirkwood/Kconfig:
config TARGET_KM_KIRKWOOD bool "KM_KIRKWOOD Board" select BOARD_LATE_INIT select DM select DM_SPI select DM_SPI_FLASH imply CMD_CRAMFS imply CMD_DIAG imply FS_CRAMFS
- in board/keymile/km_arm/Kconfig:
config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select DM select DM_SPI select DM_SPI_FLASH
Which one do you guys prefer and for what reasons? Also, I would like to know what the dummy keyword is doing in the second proposition (found that in every usage of BOARD_SPECIFIC_OPTIONS).
In the second example, "dummy" is just a comment to note that it's not a really user-visible option. I'm not sure if (for end-user ability to change things) it's better or worse than arch/.../Kconfig and doing options under the TARGET_xxx part or the third option is something like board/ti/common/Kconfig::TI_COMMON_CMD_OPTIONS where we ask the user if they want to grab a bunch of other options for a consistent experience.
That said, it really depends on what the options in question are even about. If it's "the user should have the following commands enabled" BOARD_SPECIFIC_OPTIONS and imply seems reasonable. And maybe we should make more use of this as an alternative to adding "default y if ..." statements to various Kconfig files. If we're talking about "in order to function at all we need to enable .." that should be select'ed with the TARGET_xxx option, and perhaps there should be a common symbol between these platforms so N targets select that rather than N targets select M options.
Hope that helps!