[RFCv1] doc: develop: Describe using CONFIG vs CFG for values

[Simon Glass]

Hi Tom,

On Thu, 28 Jul 2022 at 07:20, Tom Rini <trini at 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 at 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