Hi Tom,
On Thu, 28 Jul 2022 at 07:20, Tom Rini trini@konsulko.com 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?
doc/develop/build_configuration.rst | 36 +++++++++++++++++++++++++++++ doc/develop/index.rst | 1 + 2 files changed, 37 insertions(+) create mode 100644 doc/develop/build_configuration.rst
I worry that CFG is confusing as it is too similar to CONFIG. Could we have an entirely different prefix, e.g. SYS_? Also, why is a prefix needed?
I have certainly seen things that are named CONFIG_... but are really just SoC values. If they are addresses they should be in the devicetree, but perhaps for early code in SPL that is not practical.
Re the revert, why? Are you worried that we are bloating Kconfig too much with all these internal SoC settings?
What is the policy on using such things for a board? I would very much like to avoid board-specific #defines like this.
Is your hope to drop all remaining ad-hoc CONFIGs in this way?
Regards, Simon