kconfig: remove unnecessary cast in sym_get_string()

The explicit casting from (char *) to (const char *) is unneeded.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: fix memory leak in sym_warn_unmet_dep()

The string allocated in sym_warn_unmet_dep() is never freed, leading
to a memory leak when an unmet dependency is detected.

Fixes: f8f69dc0b4e0 ("kc

kconfig: fix memory leak in sym_warn_unmet_dep()

The string allocated in sym_warn_unmet_dep() is never freed, leading
to a memory leak when an unmet dependency is detected.

Fixes: f8f69dc0b4e0 ("kconfig: make unmet dependency warnings readable")
Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Petr Vorel <[email protected]>

show more ...

kconfig: add sym_get_prompt_menu() helper function

Split out the code that retrieves the menu entry with a prompt, so it
can be reused in other functions.

Signed-off-by: Masahiro Yamada <masahiroy@

kconfig: add sym_get_prompt_menu() helper function

Split out the code that retrieves the menu entry with a prompt, so it
can be reused in other functions.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: cache expression values

Cache expression values to avoid recalculating them repeatedly.

Signed-off-by: Masahiro Yamada <[email protected]>

scripts: move hash function from scripts/kconfig/ to scripts/include/

This function was originally added by commit 8af27e1dc4e4 ("fixdep: use
hash table instead of a single array").

Move it to scri

scripts: move hash function from scripts/kconfig/ to scripts/include/

This function was originally added by commit 8af27e1dc4e4 ("fixdep: use
hash table instead of a single array").

Move it to scripts/include/ so that other host programs can use it.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: split x*alloc() functions in kconfig to scripts/include/xalloc.h

These functions will be useful for other host programs.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: remove P_SYMBOL property

P_SYMBOL is a pseudo property that was previously used for data linking
purposes.

It is no longer used except for debug prints. Remove it.

Signed-off-by: Masahiro

kconfig: remove P_SYMBOL property

P_SYMBOL is a pseudo property that was previously used for data linking
purposes.

It is no longer used except for debug prints. Remove it.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: recursive checks drop file/lineno

This prevents segfault when getting filename and lineno in recursive
checks.

If the following snippet is found in Kconfig:

[Test code 1]

config FOO

kconfig: recursive checks drop file/lineno

This prevents segfault when getting filename and lineno in recursive
checks.

If the following snippet is found in Kconfig:

[Test code 1]

config FOO
bool
depends on BAR
select BAR

... without BAR defined; then there is a segfault.

Kconfig:34:error: recursive dependency detected!
Kconfig:34: symbol FOO depends on BAR
make[4]: *** [scripts/kconfig/Makefile:85: allnoconfig] Segmentation fault

This is because of the following. BAR is a fake entry created by
sym_lookup() with prop being NULL. In the recursive check, there is a
NULL check for prop to fall back to stack->sym->prop if stack->prop is
NULL. However, in this case, stack->sym points to the fake BAR entry
created by sym_lookup(), so prop is still NULL. prop was then referenced
without additional NULL checks, causing segfault.

As the previous email thread suggests, the file and lineno for select is
also wrong:

[Test code 2]

config FOO
bool

config BAR
bool

config FOO
bool "FOO"
depends on BAR
select BAR

$ make defconfig
*** Default configuration is based on 'x86_64_defconfig'
Kconfig:1:error: recursive dependency detected!
Kconfig:1: symbol FOO depends on BAR
Kconfig:4: symbol BAR is selected by FOO
[...]

Kconfig:4 should be Kconfig:10.

This patch deletes the wrong and segfault-prone filename/lineno
inference completely. With this patch, Test code 1 yields:

error: recursive dependency detected!
symbol FOO depends on BAR
symbol BAR is selected by FOO

Signed-off-by: HONG Yifan <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: remove SYMBOL_CHOICEVAL flag

This flag is unneeded because a choice member can be detected by
other means.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: add const qualifiers to several function arguments

Clarify that the given structures are not modified.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: refactor error messages in sym_check_print_recursive()

Improve the error messages and clean up redundant code.

[1] remove redundant next_sym->name checks

If 'next_sym' is a choice, the fi

kconfig: refactor error messages in sym_check_print_recursive()

Improve the error messages and clean up redundant code.

[1] remove redundant next_sym->name checks

If 'next_sym' is a choice, the first 'if' block is executed. In the
subsequent 'else if' blocks, 'next_sym" is not a choice, hence
next_sym->name is not NULL.

[2] remove redundant sym->name checks

A choice is never selected or implied by anyone because it has no name
(it is syntactically impossible). If it is, sym->name is not NULL.

[3] Show the location of choice instead of "<choice>"

"part of choice <choice>" does not convey useful information. Since a
choice has no name, it is more informative to display the file name and
line number.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: improve error message for recursive dependency in choice

Kconfig detects recursive dependencies in a choice block, but the error
message is unclear.

[Test Code]

choice
pro

kconfig: improve error message for recursive dependency in choice

Kconfig detects recursive dependencies in a choice block, but the error
message is unclear.

[Test Code]

choice
prompt "choose"
depends on A

config A
bool "A"

config B
bool "B"

endchoice

[Result]

Kconfig:1:error: recursive dependency detected!
Kconfig:1: choice <choice> contains symbol A
Kconfig:5: symbol A is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"

The phrase "contains symbol A" does not accurately describe the problem.
The issue is that the choice depends on A, which is a member of itself.

The first if-block does not print a sensible message. Remove it.

This commit improves the error message to:

Kconfig:1:error: recursive dependency detected!
Kconfig:1: symbol <choice> symbol is visible depending on A
Kconfig:5: symbol A is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: improve error message for dependency between choice members

A choice member must not depend on another member within the same choice
block.

Kconfig detects this, but the error message is n

kconfig: improve error message for dependency between choice members

A choice member must not depend on another member within the same choice
block.

Kconfig detects this, but the error message is not sensible.

[Test Code]

choice
prompt "choose"

config A
bool "A"
depends on B

config B
bool "B"

endchoice

[Result]

Kconfig:1:error: recursive dependency detected!
Kconfig:1: choice <choice> contains symbol A
Kconfig:4: symbol A is part of choice B
Kconfig:8: symbol B is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"

The phrase "part of choice B" is weird because B is not a choice block,
but a choice member.

To determine whether the current symbol is a part of a choice block,
sym_is_choice(next_sym) must be checked.

This commit improves the error message to:

Kconfig:1:error: recursive dependency detected!
Kconfig:1: choice <choice> contains symbol A
Kconfig:4: symbol A symbol is visible depending on B
Kconfig:8: symbol B is part of choice <choice>
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: fix conditional prompt behavior for choice

When a prompt is followed by "if <expr>", the symbol is configurable
when the if-conditional evaluates to true.

A typical usage is as follows:

kconfig: fix conditional prompt behavior for choice

When a prompt is followed by "if <expr>", the symbol is configurable
when the if-conditional evaluates to true.

A typical usage is as follows:

menuconfig BLOCK
bool "Enable the block layer" if EXPERT
default y

When EXPERT=n, the prompt is hidden, but this config entry is still
active, and BLOCK is set to its default value 'y'. When EXPERT=y, the
prompt is shown, making BLOCK a user-configurable option.

This usage is common throughout the kernel tree, but it has never worked
within a choice block.

[Test Code]

config EXPERT
bool "Allow expert users to modify more options"

choice
prompt "Choose" if EXPERT

config A
bool "A"

config B
bool "B"

endchoice

[Result]

# CONFIG_EXPERT is not set

When the prompt is hidden, the choice block should produce the default
without asking for the user's preference. Hence, the output should be:

# CONFIG_EXPERT is not set
CONFIG_A=y
# CONFIG_B is not set

Removing unnecessary hacks fixes the issue.

This commit also changes the behavior of 'select' by choice members.

[Test Code 2]

config MODULES
def_bool y
modules

config DEP
def_tristate m

if DEP

choice
prompt "choose"

config A
bool "A"
select C

endchoice

config B
def_bool y
select D

endif

config C
tristate

config D
tristate

The current output is as follows:

CONFIG_MODULES=y
CONFIG_DEP=m
CONFIG_A=y
CONFIG_B=y
CONFIG_C=y
CONFIG_D=m

With this commit, the output will be changed as follows:

CONFIG_MODULES=y
CONFIG_DEP=m
CONFIG_A=y
CONFIG_B=y
CONFIG_C=m
CONFIG_D=m

CONFIG_C will be changed to 'm' because 'select C' will inherit the
dependency on DEP, which is 'm'.

This change is aligned with the behavior of 'select' outside a choice
block; 'select D' depends on DEP, therefore D is selected by (B && DEP).

Note:

With this commit, allmodconfig will set CONFIG_USB_ROLE_SWITCH to 'm'
instead of 'y'. I did not see any build regression with this change.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: remove E_LIST expression type

E_LIST was preveously used to form an expression tree consisting of
choice members.

It is no longer used.

Signed-off-by: Masahiro Yamada <[email protected]

kconfig: remove E_LIST expression type

E_LIST was preveously used to form an expression tree consisting of
choice members.

It is no longer used.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: remove P_CHOICE property

P_CHOICE is a pseudo property used to link a choice with its members.

There is no more code relying on this, except for some debug code.

Signed-off-by: Masahiro Y

kconfig: remove P_CHOICE property

P_CHOICE is a pseudo property used to link a choice with its members.

There is no more code relying on this, except for some debug code.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: use sym_get_choice_menu() in sym_check_deps()

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain
the ch

kconfig: use sym_get_choice_menu() in sym_check_deps()

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain
the choice of the given choice member.

Replace it with sym_get_choice_menu(), which retrieves the choice
without relying on P_CHOICE.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: use sym_get_choice_menu() in sym_check_choice_deps()

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain

kconfig: use sym_get_choice_menu() in sym_check_choice_deps()

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain
the choice of the given choice member.

Replace it with sym_get_choice_menu(), which retrieves the choice
without relying on P_CHOICE.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: use sym_get_choice_menu() in sym_check_print_recursive()

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to ob

kconfig: use sym_get_choice_menu() in sym_check_print_recursive()

Choices and their members are associated via the P_CHOICE property.

Currently, prop_get_symbol(sym_get_choice_prop()) is used to obtain
the choice of the given choice member.

Replace it with sym_get_choice_menu(), which retrieves the choice
without relying on P_CHOICE.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: use menu_list_for_each_sym() in sym_choice_default()

Choices and their members are associated via the P_CHOICE property.

Currently, sym_get_choice_prop() and expr_list_for_each_sym() are
u

kconfig: use menu_list_for_each_sym() in sym_choice_default()

Choices and their members are associated via the P_CHOICE property.

Currently, sym_get_choice_prop() and expr_list_for_each_sym() are
used to iterate on choice members.

Replace them with menu_for_each_sub_entry(), which achieves the same
without relying on P_CHOICE.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: change sym_choice_default() to take the choice menu

Change the argument of sym_choice_default() to ease further cleanups.

Signed-off-by: Masahiro Yamada <[email protected]>

kconfig: remove sym_get_choice_value()

sym_get_choice_value(menu->sym) is equivalent to sym_calc_choice(menu).

Convert all call sites of sym_get_choice_value() and then remove it.

Signed-off-by: M

kconfig: remove sym_get_choice_value()

sym_get_choice_value(menu->sym) is equivalent to sym_calc_choice(menu).

Convert all call sites of sym_get_choice_value() and then remove it.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: refactor choice value calculation

Handling choices has always been in a PITA in Kconfig.

For example, fixes and reverts were repeated for randconfig with
KCONFIG_ALLCONFIG:

- 422c809f03f

kconfig: refactor choice value calculation

Handling choices has always been in a PITA in Kconfig.

For example, fixes and reverts were repeated for randconfig with
KCONFIG_ALLCONFIG:

- 422c809f03f0 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG")
- 23a5dfdad22a ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"")
- 8357b48549e1 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG")
- 490f16171119 ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"")

As these commits pointed out, randconfig does not randomize choices when
KCONFIG_ALLCONFIG is used. This issue still remains.

[Test Case]

choice
prompt "choose"

config A
bool "A"

config B
bool "B"

endchoice

$ echo > all.config
$ make KCONFIG_ALLCONFIG=1 randconfig

The output is always as follows:

CONFIG_A=y
# CONFIG_B is not set

Not only randconfig, but other all*config variants are also broken with
KCONFIG_ALLCONFIG.

With the same Kconfig,

$ echo '# CONFIG_A is not set' > all.config
$ make KCONFIG_ALLCONFIG=1 allyesconfig

You will get this:

CONFIG_A=y
# CONFIG_B is not set

This is incorrect because it does not respect all.config.

The correct output should be:

# CONFIG_A is not set
CONFIG_B=y

To handle user inputs more accurately, this commit refactors the code
based on the following principles:

- When a user value is given, Kconfig must set it immediately.
Do not defer it by setting SYMBOL_NEED_SET_CHOICE_VALUES.

- The SYMBOL_DEF_USER flag must not be cleared, unless a new config
file is loaded. Kconfig must not forget user inputs.

In addition, user values for choices must be managed with priority.
If user inputs conflict within a choice block, the newest value wins.
The values given by randconfig have lower priority than explicit user
inputs.

This commit implements it by using a linked list. Every time a choice
block gets a new input, it is moved to the top of the list.

Let me explain how it works.

Let's say, we have a choice block that consists of five symbols:
A, B, C, D, and E.

Initially, the linked list looks like this:

A(=?) --> B(=?) --> C(=?) --> D(=?) --> E(=?)

Suppose randconfig is executed with the following KCONFIG_ALLCONFIG:

CONFIG_C=y
# CONFIG_A is not set
CONFIG_D=y

First, CONFIG_C=y is read. C is set to 'y' and moved to the top.

C(=y) --> A(=?) --> B(=?) --> D(=?) --> E(=?)

Next, '# CONFIG_A is not set' is read. A is set to 'n' and moved to
the top.

A(=n) --> C(=y) --> B(=?) --> D(=?) --> E(=?)

Then, 'CONFIG_D=y' is read. D is set to 'y' and moved to the top.

D(=y) --> A(=n) --> C(=y) --> B(=?) --> E(=?)

Lastly, randconfig shuffles the order of the remaining symbols,
resulting in:

D(=y) --> A(=n) --> C(=y) --> B(=y) --> E(=y)
or
D(=y) --> A(=n) --> C(=y) --> E(=y) --> B(=y)

When calculating the output, the linked list is traversed and the first
visible symbol with 'y' is taken. In this case, it is D if visible.

If D is hidden by 'depends on', the next node, A, is examined. Since
it is already specified as 'n', it is skipped. Next, C is checked, and
selected if it is visible.

If C is also invisible, either B or E is chosen as a result of the
randomization.

If B and E are also invisible, the linked list is traversed in the
reverse order, and the least prioritized 'n' symbol is chosen. It is
A in this case.

Now, Kconfig remembers all user values. This is a big difference from
the previous implementation, where Kconfig would forget CONFIG_C=y when
CONFIG_D=y appeared in the same input file.

The new appaorch respects user-specified values as much as possible.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: introduce choice_set_value() helper

Currently, sym_set_tristate_value() is used to set 'y' to a choice
member, which is confusing because it not only sets 'y' to the given
symbol but also t

kconfig: introduce choice_set_value() helper

Currently, sym_set_tristate_value() is used to set 'y' to a choice
member, which is confusing because it not only sets 'y' to the given
symbol but also tweaks flags of other symbols as a side effect.

Add a dedicated function for setting the value of the given choice.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: remove tristate choice support

I previously submitted a fix for a bug in the choice feature [1], where
I mentioned, "Another (much cleaner) approach would be to remove the
tristate choice s

kconfig: remove tristate choice support

I previously submitted a fix for a bug in the choice feature [1], where
I mentioned, "Another (much cleaner) approach would be to remove the
tristate choice support entirely".

There are more issues in the tristate choice feature. For example, you
can observe a couple of bugs in the following test code.

[Test Code]

config MODULES
def_bool y
modules

choice
prompt "tristate choice"
default A

config A
tristate "A"

config B
tristate "B"

endchoice

Bug 1: the 'default' property is not correctly processed

'make alldefconfig' produces:

CONFIG_MODULES=y
# CONFIG_A is not set
# CONFIG_B is not set

However, the correct output should be:

CONFIG_MODULES=y
CONFIG_A=y
# CONFIG_B is not set

The unit test file, scripts/kconfig/tests/choice/alldef_expected_config,
is wrong as well.

Bug 2: choice members never get 'y' with randconfig

For the test code above, the following combinations are possible:

A B
(1) y n
(2) n y
(3) m m
(4) m n
(5) n m
(6) n n

'make randconfig' never produces (1) or (2).

These bugs are fixable, but a more critical problem is the lack of a
sensible syntax to specify the default for the tristate choice.
The default for the choice must be one of the choice members, which
cannot specify any of the patterns (3) through (6) above.

In addition, I have never seen it being used in a useful way.

The following commits removed unnecessary use of tristate choices:

- df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers")
- bfb57ef0544a ("rapidio: remove choice for enumeration")

This commit removes the tristate choice support entirely, which allows
me to delete a lot of code, making further refactoring easier.

Note:
This includes the revert of commit fa64e5f6a35e ("kconfig/symbol.c:
handle choice_values that depend on 'm' symbols"). It was suspicious
because it did not address the root cause but introduced inconsistency
in visibility between choice members and other symbols.

[1]: https://lore.kernel.org/linux-kbuild/[email protected]/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...