On Thu, Jul 28, 2022 at 03:34:43PM +0200, Pali Rohár wrote:
On Thursday 28 July 2022 09:20:46 Tom Rini wrote:
Document how and when to use CONFIG or CFG namespace for options. There are times where Kconfig is not a great fit for our needs, so we want to use the CFG namespace instead.
Signed-off-by: Tom Rini trini@konsulko.com
RFCv1:
- This is essentially my idea on how to better handle the problem of CONFIG values that just don't fit in Kconfig because it makes much more sense to define them statically for a given SoC or calculate them from other values, and so on. One example here would be to revert c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig") and re-name these to CFG_SYS_.. instead. Another big example here would be a global search-and-replace of 's/CONFIG_HPS_/CFG_HPS_/g' as that's all tool-generated. Not all CONFIG_SYS_ options would get this as boolean choices are well handled in Kconfig, and that may not be clear enough in what I wrote here?
In README is also written:
Ah yes, I forgot to see if the README had anything here. I'll remove and incorporate in RFCv2.
Configuration _OPTIONS_: These are selectable by the user and have names beginning with "CONFIG_".
Configuration _SETTINGS_: These depend on the hardware etc. and should not be meddled with if you don't know what you're doing; they have names beginning with "CONFIG_SYS_".
So based on this statement, proposed CFG_* options should be of second category - not selectable by user - right?
Right.
And this reminds me, that CONFIG_SYS_* option in Kconfig should also not be possible to select / change by user or in user's defconfig. This can be achieved in Kconfig by _not_ specifying short description (after "bool" or "hex" keyword). So maybe this should be also fixed? Or at least do not introduce new Kconfig options with SYS_* which can be changed?
There is a lot of possible follow-up cleanup work to do, yes. I gave one example of an unmigration that should be done, but there's certainly more. I'll try and make it clearer in RFCv2 about when it is appropriate to add CONFIG settings but that aren't configurable.
[snip]
This change looks good. But I'm not sure how to correctly do it. It would be nice to see example, e.g. how to handle it for revert of c7fad78ec0ee ("Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"). Those are board specific options which are exported and required by both u-boot drivers and u-boot arch/cpu code.
I'll probably just start with a revert + sed, and leave further clean-up to whomever has more time and interest on the legacy platforms, for that specific example. For all of the SYS_INIT_SP_ADDR as another example, I'll probably go with renaming to CFG_SYS_INIT_SP_ADDR and CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR being select'd and CONFIG_CUSTOM_SYS_INIT_SP_ADDR becoming CFG_SYS_INIT_SP_ADDR directly, and in board.h until someone has the time and desire to further rectify something that really shouldn't be board, but rather SoC (and adjusted based on further options) specific.