From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 23 Jan 2017 22:30:29 -0500 Subject: [U-Boot] [PATCH 03/11] Convert CONFIG_ARCH_EARLY_INIT_R to Kconfig In-Reply-To: References: <20170123203127.19240-1-sjg@chromium.org> <20170123203127.19240-4-sjg@chromium.org> Message-ID: <20170124033029.GF22316@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Jan 24, 2017 at 11:36:11AM +0900, Masahiro Yamada wrote: > Hi Simon, Tom. > > 2017-01-24 5:31 GMT+09:00 Simon Glass : > > This converts the following to Kconfig: > > CONFIG_ARCH_EARLY_INIT_R > > > > Signed-off-by: Simon Glass > > --- > > > > 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/ I will probably end up moving this to all select iff it ends up with no size change. > [2] How painful is it to use __weak function > instead of CONFIG_ARCH_EARLY_INIT_R For something that's only in U-Boot proper? Probably not bad, but a follow-up. > [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. This is indeed problematic and partly why moving this to 'select' isn't trivial as some of the locations of the functions make it unclear enough if the right answer isn't instead to move this elsewhere. My first guess is that on 'rut' the LCD needs to be visible asap for the "it's alive!" factor. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: