Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33142 )
Change subject: Kconfig: Create coreboot separate stage kconfigs ......................................................................
Patch Set 2:
Patch Set 2: Code-Review-1
(1 comment)
Sorry, I still think this patch is a bad idea and just adding to confusion and redundancy in the configs. The architecture stage Kconfigs are just meant to select the right toolchain, they don't actually mean that that stage is included and I don't think they need to. ARCH_VERSTAGE_XXX is often set even when we don't actually have a verstage (and I also don't see how you're disabling ARCH_RAMSTAGE_XXX in your case?). Trying to solve this all at this level would pull a lot of stuff into the architecture configs where it needs to be unnecessarily duplicated six times.
If you want to know whether you have a verstage, check CONFIG_SEPARATE_VERSTAGE. If you want to know whether you have a ramstage, check CONFIG_RAMPAYLOAD. Those options already correspond 1-to-1 to what you want to know, I don't see the need for adding any further ones. If at some future point we have more than one case where there's no ramstage, we can add a helper option and select that based on RAMPAYLOAD. But for now I don't see why we need to add anything, and we definitely shouldn't need to pull all of this into the toolchain selectors.
There's new requirements that are surfacing:
Being able to mix and match stages. e.g. remove bootblock, verstage, but leave romstage and ramstage.
The stage options that exist are for selecting the toolchain, but they can also indicate the presence and desire of a particular stage. There's 2 options on indicating positive selection of the present of the stages:
1. Annotate all the soc/higher level Kconfig selections (most likely higher change churn than just arch). 2. Update arch/ to select the presence of the stage. One-time change per arch. Adding new archs will be straight forward since they'll just copy what's there and not need to know about yet another Kconfig (previous versions of this patch did that).
They both need to deal with conditionally including and excluding things such as CONFIG_RAMPAYLOAD that may be selectable. So one might need to bite the bullet and update more, like in soc, along with some special helpers.
The soc/higher level Kconfigs are currently driving things as they are the root. I'm not sure why there would be unnecessary duplication.