Hi Heinrich, On Tue, 7 Feb 2023 at 01:40, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > On 2/7/23 05:02, Simon Glass wrote: > > Hi Heinrich, > > > > On Mon, 6 Feb 2023 at 16:41, Heinrich Schuchardt > > <heinrich.schucha...@canonical.com> wrote: > >> > >> > >> > >> On 2/5/23 23:39, Simon Glass wrote: > >>> This converts 1 usage of this option to the non-SPL form, since there is > >>> no SPL_EFI_TCG2_PROTOCOL defined in Kconfig > >> > >> Why do you touch the code? I can't see any problem being solved. > > > > CONFIG_IS_ENABLED() is going away, so we need to migrate things that > > should not be using it. I understand that EFI is not used in SPL, so > > it is also redundant. > > > > Neither the cover letter of this series nor the commit message of this > patch says that CONFIG_IS_ENABLED() is going away. > > Both the cover letter and the commit message of the individual patches > should clearly indicate this intention. > > Why do you want to eliminate CONFIG_IS_ENABLED()? What is going to > replace it?
Please see the comments here: https://patchwork.ozlabs.org/project/uboot/cover/20230206190550.1692420-1-...@chromium.org/ This work is happening in three different series: u-boot-dm/spla-working - ensures that Kconfig options mentioned in the source code actually exist in Kconfig u-boot-dm/splb-working - drops use of CONFIG_IS_ENABLED() where it is not necessary u-boot-dm/splc-working - adds SPL Kconfigs which are referred to in the source; converts to a split config Fundamentally it is about having CONFIG_FOO mean the same thing in all builds (U-Boot proper, SPL, etc.): FOO is enabled in this build. It means we can drop the SPL_TPL_ macro and also the use of CONFIG_IS_ENABLED(). This discussion has been going on for many years. Unfortunately it is extremely difficult to achieve. What started off as 30 patches and turned into a lot... Regards, Simon