Hi Simon, Tom.
2017-01-24 5:31 GMT+09:00 Simon Glass sjg@chromium.org:
This converts the following to Kconfig: CONFIG_ARCH_EARLY_INIT_R
Signed-off-by: Simon Glass sjg@chromium.org
arch/Kconfig | 1 + arch/arc/include/asm/config.h | 1 - arch/arm/Kconfig | 1 + arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 4 ++++ common/Kconfig | 13 +++++++++++++ configs/bayleybay_defconfig | 1 + configs/cougarcanyon2_defconfig | 1 + configs/dfi-bt700-q7x-151_defconfig | 1 + configs/efi-x86_defconfig | 1 + configs/minnowmax_defconfig | 1 + configs/mvebu_db-88f3720_defconfig | 1 + configs/mvebu_db-88f7040_defconfig | 1 + configs/mvebu_db-88f8040_defconfig | 1 + configs/qemu-x86_efi_payload32_defconfig | 1 + configs/qemu-x86_efi_payload64_defconfig | 1 + configs/rut_defconfig | 1 + configs/theadorable-x86-dfi-bt700_defconfig | 1 +
I have some questions
[1] Is this a user-configurable symbol?
You use "select" in some places, but add it in defconfig in others.
This is controlling whether arch_early_init_r() is called from common/board_r.c or not, right?
Does it make sense to skip the init function if users want to?
Maybe, Tom will end up with converting all of them to "select" like this? http://patchwork.ozlabs.org/patch/718315/
[2] How painful is it to use __weak function instead of CONFIG_ARCH_EARLY_INIT_R
[3] We have board_early_init_r() for board-specific init procedure.
From its function name, I thought arch_early_init_r() is
called for arch-specific (ARC, ARM, x86) init. In fact, it is not. ARC is good. For ARM, x86, it is abused for board specific init.
For example,
board/siemens/rut/board.c
int arch_early_init_r(void) { enable_lcd(); return 0; }
This is apparently board_init, not arch_init.