Hi Tom,
On Sun, 31 Jul 2022 at 05:46, Tom Rini <tr...@konsulko.com> wrote:
>
> On Sat, Jul 30, 2022 at 07:27:31PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 28 Jul 2022 at 07:20, Tom Rini <tr...@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 <tr...@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?
>
> We need a prefix here for consistency. I don't want to use just SYS_
> here as that's not always used for some of the values to be converted.
We could add it. I feel that people new to the code base will find it
confusing that we have CONFIG and CFG.
>
> > 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.
>
> I tried to elaborate on this more in the later revs of the document.
> But yes, we have some legacy code that's just not going to get a massive
> rewrite to use device tree more, but also has an active enough user base
> that we aren't just going to drop it. So long as it's not going to make
> life harder in the rest of the code base, this feels like a good enough
> compromise.
OK I see.
>
> > Re the revert, why? Are you worried that we are bloating Kconfig too
> > much with all these internal SoC settings?
>
> As Pali explained in other threads, there was a problem with the values
> in that commit, prior to conversion. But turning the series of ORs and
> shifts into a single magic value made it much harder to see and address.
> Yes, if it was written to pull from the device tree, it would have been
> easier to read and fix there. But no one is going to rewrite all of the
> core PowerPC code.
OK.
>
> > What is the policy on using such things for a board? I would very much
> > like to avoid board-specific #defines like this.
>
> The policy is better laid out in later revs of the document I think.
>
> > Is your hope to drop all remaining ad-hoc CONFIGs in this way?
>
> A large chunk, yes. I'm auditing CONFIG_SYS_* still, but there's
> probably going a few hundred symbols that just get resolved this way.
Reviewed-by: Simon Glass <s...@chromium.org>
Regards,
Simon
