From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Tue, 29 Sep 2015 10:38:54 +0200 Subject: [U-Boot] [PATCH 03/11] Kconfig: add CONFIG_SYS_BOOTM_LEN In-Reply-To: <20150928211248.GI22966@bill-the-cat> References: <1443029143-22313-1-git-send-email-ryan.harkin@linaro.org> <1443029143-22313-4-git-send-email-ryan.harkin@linaro.org> <20150928151053.GH22966@bill-the-cat> <5609937B.8000309@redhat.com> <20150928211248.GI22966@bill-the-cat> Message-ID: <560A4E1E.7070206@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 28-09-15 23:12, Tom Rini wrote: > On Mon, Sep 28, 2015 at 09:22:35PM +0200, Hans de Goede wrote: >> Hi, >> >> On 28-09-15 17:10, Tom Rini wrote: >>> On Wed, Sep 23, 2015 at 10:25:35AM -0700, Ryan Harkin wrote: >>> >>>> As config migrates from board config files to Kconfig, when adding >>>> CONFIG_SYS_BOOTM_LEN to a platform, I decided to add >>>> Kconfig support for CONFIG_SYS_BOOTM_LEN. >>>> >>>> Signed-off-by: Ryan Harkin >>>> Reviewed-by: Linus Walleij >>>> CC: Masahiro Yamada >>>> CC: Simon Glass >>>> CC: Linus Walleij >>> >>> Thanks for trying to do this. The problem however is that you need to >>> use tools/moveconfig.py so that all of the other boards (which is a lot) >>> get updated too, otherwise they fail to build. >> >> No, just no, not more polluting of defconfig files with things which really >> belong in a per SoC file not a per board file. > > Well, we should be putting SoC/arch-specific stuff into the defaults Agreed, but where, do we add a long list of: default FOO if ARCH_BAR To the Kconfig file where the actual CONFIG_SOMETHING gets defined, or do we add it to board/bar/Kconfig ? Currently we've a bit of a mix, I personally prefer the board/bar/Kconfig version as that puts everything for one SoC(-family) in one place and it helps avoiding merge conflicts. > and > also using this as a chance to look at places where defaults differ > pointlessly. > > But, I also hear your concern. I see Masahiro has been working with > merge_config.sh from the kernel in the kernel. How crazy would it be > to re-work things (in some cases..) to have a merge in the config > process so that there could be a sunxi-common config fragment. Either we then ask the user to take an extra step during building (not a good idea IMHO), or we somehow need to automate this, which is hard because figuring out which foo_common_config fragment belongs to which board_defconfig file is going to be hard and / or will involve a long list of hardcoded values in a Makefile or some such. > Or > can/should we really just use default foo if Y in more places. I believe that this is the better option, currently board/sunxi/Kconfig already has: config SYS_CLK_FREQ default 912000000 if MACH_SUN7I default 1008000000 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I config SYS_CONFIG_NAME default "sun4i" if MACH_SUN4I default "sun5i" if MACH_SUN5I default "sun6i" if MACH_SUN6I default "sun7i" if MACH_SUN7I default "sun8i" if MACH_SUN8I default "sun9i" if MACH_SUN9I Apparently these are not a problem for the script which is used to rewrite all the defconfig-s, where as in the past having: config CMD_FOO default y in board/sunxi/Kconfig was a problem (it caused the script to emit a ton of warnings IIRC) so I guess that doing something like: config FOO default bar if ARCH_SUNXI Will workaround the script issuing all kind of warnings, and then we can keep per SoC(-family) defaults in board/foo/Kconfig. Regards, Hans