> -----Original Message-----
> From: Tom Rini <tr...@konsulko.com>
> Sent: Tuesday, March 18, 2025 9:58 PM
> To: Chee, Tien Fong <tien.fong.c...@altera.com>
> Cc: u-boot@lists.denx.de
> Subject: Re: [PATCH] ARM: socfpga: Drop incorrect imply
> SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION*
>
> On Tue, Mar 18, 2025 at 03:11:44AM +0000, Chee, Tien Fong wrote:
> > Hi Tony,
> >
> > > -----Original Message-----
> > > From: Tom Rini <tr...@konsulko.com>
> > > Sent: Saturday, March 15, 2025 9:29 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Chee, Tien Fong <tien.fong.c...@altera.com>
> > > Subject: [PATCH] ARM: socfpga: Drop incorrect imply
> > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION*
> > >
> > > The use of both "imply
> > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION" and "imply
> > > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE" here is
> wrong as those
> > > are both part of the same choice statement. Furthermore you cannot
> > > select/imply something from a choice statement, it must be a
> > > "default ...
> > > if ..." construct within the choice statement in question.
> >
> > I think the imply here which allows for overwritten in defconfig.
>
> It doesn't. The specific warning is that these imply statements have no
> effect.
Okay, I'm not aware this now is not working, because I tested this worked long
time ago.
>
> > To support the "default....if...", new config for platform specific in
> > Kconfig is required. Is there any other approach better to support
> > this?
>
> Adding "default SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION if ..."
> to the choice statement is fine. But the follow-up question is if it's
> something
> worth being listed like that compared with just being set as needed in the
> defconfig.
Yeah, I see the value in this, imagine most of device defconfig need this
config, then this can be centralized here with imply instead of adding this
config to respective defconfig for looking neat. Minor devices which this
config is not required to be enabled, this can be overwritten to disable in
their respective defconfig.
>
> --
> Tom
