On Fri, Sep 05, 2025 at 08:19:59AM -0600, Tom Rini wrote:
> On Wed, Sep 03, 2025 at 12:56:50PM +0200, Philip Oberfichtner wrote:
>
> > Use a consistent logic for image size checks. No functional change.
> >
> > Before this commit, there were two concurrent approaches of how image
> > size checks are disabled: Whereas BOARD_SIZE_LIMIT was gated through a
> > dedicated Kconfig symbol to achieve this, all the other size checks were
> > disabled by assigning them a limit of zero bytes.
> >
> > By this commit we achieve a consistent logic for size limiting, by
> > introducing CONFIG_HAS_XXX_SIZE_LIMIT for all those options that don't
> > have it yet.
> >
> > Signed-off-by: Philip Oberfichtner <[email protected]>
<...>
> > diff --git a/arch/x86/cpu/apollolake/Kconfig
> > b/arch/x86/cpu/apollolake/Kconfig
> > index 5dd866ffcfe..d70e8def36f 100644
> > --- a/arch/x86/cpu/apollolake/Kconfig
> > +++ b/arch/x86/cpu/apollolake/Kconfig
> > @@ -78,8 +78,11 @@ config MMCONF_BASE_ADDRESS
> > hex
> > default 0xe0000000
> >
> > +config HAS_TPL_SIZE_LIMIT
> > + default y
> > +
> > config TPL_SIZE_LIMIT
> > - default 0x7800
> > + default 0x7800 if HAS_TPL_SIZE_LIMIT
> >
> > config CPU_ADDR_BITS
> > default 39
>
> These should be "default y if .." in the main Kconfig entry for the
> option.
Not sure if I'm following you here. So you mean both of the defaults
should be moved to common/spl/Kconfig.tpl? - like
config HAS_TPL_SIZE_LIMIT
[...]
default y if INTEL_APOLLOLAKE
config TPL_SIZE_LIMIT
[...]
default 0x7800 if INTEL_APOLLOLAKE
>
> > diff --git a/configs/am62ax_evm_r5_defconfig
> > b/configs/am62ax_evm_r5_defconfig
>
> The reset of these, to Marek's point, show that we need to also add
> "default y if .." for a number of other platforms too.
Which platforms exactly?
> At least the ones
> where today we have default limits provided in Kconfig today.
Besides the ones handled above, i.e.
arch/arm/mach-socfpga/Kconfig,
arch/mips/mach-mtmips/Kconfig and
arch/x86/cpu/apollolake/Kconfig,
there aren't any.
I myself am not very fond of changing that many defconfigs, but I still
don't see a way of avoiding it. I guess it would become more clear if
you concretely name a few examples.
Best regards,
Philip
