Hi Massimo,
On 10/14/26 8:22 PM, Massimo Pegorer wrote:
Hi Quentin,
Il giorno mer 14 ott 2026 alle ore 18:25 Quentin Schulz
<[email protected]> ha scritto:
Hi Massimo,
On 10/2/26 6:36 PM, Massimo Pegorer wrote:
The configuration options SPL_BSS_START_ADDR and SPL_BSS_MAX_SIZE are
guarded by SPL_HAS_BSS_LINKER_SECTION and SPL_BSS_LIMIT options in the
common/spl/Kconfig file where they are originally defined. Addition of
a second config statement without 'depends on' guard causes these two
options to be put in the configuration even when the guard is not
selected, which is unneeded and sounds wrong.
I'm sorry, I don't understand the issue. Can you clarify or provide a
way to reproduce the issue? Multiple definitions of the same Kconfig
symbol are "combined" as far as I know so this shouldn't be an issue.
The reasoning is almost the same I've tried to explain in [1]. Sorry if it
sounds like ancillary changes. But in this way qconfig tool is more effective
and helpful.
OK, so I *really* do not want to start doing this, especially if we
don't have anything to make sure we don't do the same "mistake" again in
the future. I'm sure there are *tons* of other symbols with a similar
issue. I was under the impression that Kconfig would simply merge
symbols of the same name, but this behavior seems to indicate there's
some additional gotchas (or bugs). It'd be nice to know if upstream
Linux suffers from the same issue or not. If not, then it's likely
because we are far behind Linux for the Kconfig we use. If it is, then
maybe it's a bug the Linux kernel isn't aware of and we/they should fix,
or the documentation isn't clear enough on how we can specify additional
information by "redefining" the symbol.
There could be some issue depending on the parsing order for the
symbols, I think there's an importance for which symbol gets parsed
first before it is "redefined".
Can you try to reproduce with the Linux kernel? Does anyone have an idea
on how to tackle this issue maybe?
Cheers,
Quentin
