On Tue, Apr 19, 2022 at 01:11:23PM +0900, AKASHI Takahiro wrote: > On Mon, Apr 18, 2022 at 11:09:38PM -0400, Tom Rini wrote: > > On Tue, Apr 19, 2022 at 10:01:54AM +0900, AKASHI Takahiro wrote: > > > > > Some defconfig enables CMD_PART even if none of any partition table > > > types (CONFIG_*_PARTITION) are enabled. > > > This will lead to the size growth in SPL/TPL code since disk/part.c > > > will be compiled in any way. > > > We will change disk/Kconfig later so that CONFIG_PARTITIONS is only > > > enabled when, at least, one of CONFIG_*_PARTITION is enabled. > > > > > > To make the build work (in particular, "part" command) correctly, > > > a few functions should be defined as void functions in case of > > > !CONFIG_PARTITIONS. > > > > > > Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org> > > > > I guess I wonder why we don't just make CMD_PART depend on PARTITIONS > > now and thus correct the few (single?) board that has this enabled > > without underlying partition code by removing the can't be functional > > cmd. > > Well, that is partially what I did in my RFC and I thought > that you declined to accept my change. > Did I misunderstand you?
Yes, I wasn't clear, sorry for the confusion. Just this part of the series should be replaced with making CMD_PART depend on PARTITIONS and if there really is a use case for 'part' without PARTITION support (rather than it being an unintentionally enabled feature) we can deal with it then. The rest of the series looks good to me and I'll let Heinrich comment on the EFI specific parts. -- Tom
signature.asc
Description: PGP signature
