kconfig: show sub-menu entries even if the prompt is hidden

Since commit f79dc03fe68c ("kconfig: refactor choice value
calculation"), when EXPERT is disabled, nothing within the "if INPUT"
... "endi

kconfig: show sub-menu entries even if the prompt is hidden

Since commit f79dc03fe68c ("kconfig: refactor choice value
calculation"), when EXPERT is disabled, nothing within the "if INPUT"
... "endif" block in drivers/input/Kconfig is displayed. This issue
affects all command-line interfaces and GUI frontends.

The prompt for INPUT is hidden when EXPERT is disabled. Previously,
menu_is_visible() returned true in this case; however, it now returns
false, resulting in all sub-menu entries being skipped.

Here is a simplified test case illustrating the issue:

config A
bool "A" if X
default y

config B
bool "B"
depends on A

When X is disabled, A becomes unconfigurable and is forced to y.
B should be displayed, as its dependency is met.

This commit restores the necessary code, so menu_is_visible() functions
as it did previously.

Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation")
Reported-by: Edmund Raile <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kconfig: use hash table to reuse expressions

Currently, every expression in Kconfig files produces a new abstract
syntax tree (AST), even if it is identical to a previously encountered
one.

Conside

kconfig: use hash table to reuse expressions

Currently, every expression in Kconfig files produces a new abstract
syntax tree (AST), even if it is identical to a previously encountered
one.

Consider the following code:

config FOO
bool "FOO"
depends on (A || B) && C

config BAR
bool "BAR"
depends on (A || B) && C

config BAZ
bool "BAZ"
depends on A || B

The "depends on" lines are similar, but currently a separate AST is
allocated for each one.

The current data structure looks like this:

FOO->dep ==> AND BAR->dep ==> AND BAZ->dep ==> OR
/ \ / \ / \
OR C OR C A B
/ \ / \
A B A B

This is redundant; FOO->dep and BAR->dep have identical ASTs but
different memory instances.

We can optimize this; FOO->dep and BAR->dep can share the same AST, and
BAZ->dep can reference its sub tree.

The optimized data structure looks like this:

FOO->dep, BAR->dep ==> AND
/ \
BAZ->dep ==> OR C
/ \
A B

This commit introduces a hash table to keep track of allocated
expressions. If an identical expression is found, it is reused.

This does not necessarily result in memory savings, as menu_finalize()
transforms expressions without freeing up stale ones. This will be
addressed later.

One optimization that can be easily implemented is caching the
expression's value. Once FOO's dependency, (A || B) && C, is calculated,
it can be cached, eliminating the need to recalculate it for BAR.

This commit also reverts commit e983b7b17ad1 ("kconfig/menu.c: fix
multiple references to expressions in menu_add_prop()").

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: stop adding P_SYMBOL property to symbols

I believe its last usage was in the following code:

if (prop == NULL)
prop = stack->sym->prop;

This code was previously used to pr

kconfig: stop adding P_SYMBOL property to symbols

I believe its last usage was in the following code:

if (prop == NULL)
prop = stack->sym->prop;

This code was previously used to print the file name and line number of
associated symbols in sym_check_print_recursive(), which was removed by
commit 9d0d26604657 ("kconfig: recursive checks drop file/lineno").

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

show more ...

kbuild: move some helper headers from scripts/kconfig/ to scripts/include/

Move array_size.h, hashtable.h, list.h, list_types.h from scripts/kconfig/
to scripts/include/.

These headers will be usef

kbuild: move some helper headers from scripts/kconfig/ to scripts/include/

Move array_size.h, hashtable.h, list.h, list_types.h from scripts/kconfig/
to scripts/include/.

These headers will be useful for other host programs.

Remove scripts/mod/list.h.

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: 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 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: 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: 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 ...

kconfig: remove wrong expr_trans_bool()

expr_trans_bool() performs an incorrect transformation.

[Test Code]

config MODULES
def_bool y
modules

config A

kconfig: remove wrong expr_trans_bool()

expr_trans_bool() performs an incorrect transformation.

[Test Code]

config MODULES
def_bool y
modules

config A
def_bool y
select C if B != n

config B
def_tristate m

config C
tristate

[Result]

CONFIG_MODULES=y
CONFIG_A=y
CONFIG_B=m
CONFIG_C=m

This output is incorrect because CONFIG_C=y is expected.

Documentation/kbuild/kconfig-language.rst clearly explains the function
of the '!=' operator:

If the values of both symbols are equal, it returns 'n',
otherwise 'y'.

Therefore, the statement:

select C if B != n

should be equivalent to:

select C if y

Or, more simply:

select C

Hence, the symbol C should be selected by the value of A, which is 'y'.

However, expr_trans_bool() wrongly transforms it to:

select C if B

Therefore, the symbol C is selected by (A && B), which is 'm'.

The comment block of expr_trans_bool() correctly explains its intention:

* bool FOO!=n => FOO
^^^^

If FOO is bool, FOO!=n can be simplified into FOO. This is correct.

However, the actual code performs this transformation when FOO is
tristate:

if (e->left.sym->type == S_TRISTATE) {
^^^^^^^^^^

While it can be fixed to S_BOOLEAN, there is no point in doing so
because expr_tranform() already transforms FOO!=n to FOO when FOO is
bool. (see the "case E_UNEQUAL" part)

expr_trans_bool() is wrong and unnecessary.

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

show more ...

kconfig: use sym_get_choice_menu() in sym_check_prop()

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_prop()

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: turn defaults and additional prompt for choice members into error

menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard erro

kconfig: turn defaults and additional prompt for choice members into error

menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard errors.

While I was here, I moved the checks to slim down menu_finalize().

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

show more ...

kconfig: turn missing prompt for choice members into error

Choice members must have a prompt; hence make it an error.

While I was here, I moved the check to the parser to slim down
_menu_finalize()

kconfig: turn missing prompt for choice members into error

Choice members must have a prompt; hence make it an error.

While I was here, I moved the check to the parser to slim down
_menu_finalize().

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

show more ...

kconfig: remove 'optional' property support

The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.

In the followin

kconfig: remove 'optional' property support

The 'choice' statement is primarily used to exclusively select one
option, but the 'optional' property allows all entries to be disabled.

In the following example, both A and B can be disabled simultaneously:

choice
prompt "choose A, B, or nothing"
optional

config A
bool "A"

config B
bool "B"

endchoice

You can achieve the equivalent outcome by other means.

A common solution is to add another option to guard the choice block.
In the following example, you can set ENABLE_A_B_CHOICE=n to disable
the entire choice block:

choice
prompt "choose A or B"
depends on ENABLE_A_B_CHOICE

config A
bool "A"

config B
bool "B"

endchoice

Another approach is to insert one more entry:

choice
prompt "choose A, B, or disable both"

config A
bool "A"

config B
bool "B"

config DISABLE_A_AND_B
bool "choose this to disable both A and B"

endchoice

Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE,
LTO_NONE, etc.

The 'optional' property is even more unnecessary for a tristate choice.

Without the 'optional' property, you can disable A and B; you can set
'm' in the choice prompt, and disable A and B individually:

choice
prompt "choose one built-in or make them modular"

config A
tristate "A"

config B
tristate "B"

endchoice

In conclusion, the 'optional' property was unneeded.

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

show more ...

kconfig: add menu_next() function and menu_for_each(_sub)_entry macros

Several functions require traversing menu entries sequentially. This
commit introduces some helpers to simplify such operations

kconfig: add menu_next() function and menu_for_each(_sub)_entry macros

Several functions require traversing menu entries sequentially. This
commit introduces some helpers to simplify such operations.

The menu_next() function facilitates depth-first traversal:

1. Descend to the child level if the current menu has one
2. Move to the next sibling at the same level if available
3. Ascend to the parent level if there is no more child or sibling

The menu_for_each_sub_entry() macro iterates over all submenu entries
using depth-first traverse.

The menu_for_each_entry() macro is the same, but over all menu entries.

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

show more ...

kconfig: do not reparent the menu inside a choice block

The boolean 'choice' is used to list exclusively selected config
options.

You must not add a dependency between choice members, because such

kconfig: do not reparent the menu inside a choice block

The boolean 'choice' is used to list exclusively selected config
options.

You must not add a dependency between choice members, because such a
dependency would create an invisible entry.

In the following test case, it is impossible to choose 'C'.

[Test Case 1]

choice
prompt "Choose one, but how to choose C?"

config A
bool "A"

config B
bool "B"

config C
bool "C"
depends on A

endchoice

Hence, Kconfig shows the following error message:

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

However, Kconfig does not report anything for the following similar code:

[Test Case 2]

choice
prompt "Choose one, but how to choose B?"

config A
bool "A"

config B
bool "B"
depends on A

config C
bool "C"

endchoice

This is because menu_finalize() reparents the menu tree when an entry
depends on the preceding one.

With reparenting, the menu tree:

choice
|- A
|- B
\- C

... will be transformed into the following structure:

choice
|- A
| \- B
\- C

Consequently, Kconfig considers only 'A' and 'C' as choice members.
This behavior is awkward. The second test case should be an error too.

This commit stops reparenting inside a choice.

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

show more ...

kconfig: check prompt for choice while parsing

This can be checked on-the-fly.

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

kconfig: use linked list in get_symbol_str() to iterate over menus

Currently, get_symbol_str() uses a tricky approach to traverse the
associated menus.

With relevant menus now linked to the symbol

kconfig: use linked list in get_symbol_str() to iterate over menus

Currently, get_symbol_str() uses a tricky approach to traverse the
associated menus.

With relevant menus now linked to the symbol using a linked list,
use list_for_each_entry() for iterating on the menus.

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

show more ...

kconfig: link menus to a symbol

Currently, there is no direct link from (struct symbol) to (struct menu).

It is still possible to access associated menus through the P_SYMBOL
property, because prop

kconfig: link menus to a symbol

Currently, there is no direct link from (struct symbol) to (struct menu).

It is still possible to access associated menus through the P_SYMBOL
property, because property::menu is the relevant menu entry, but it
results in complex code, as seen in get_symbol_str().

Use a linked list for simpler traversal of relevant menus.

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

show more ...

kconfig: do not imply the type of choice value

Do not feed back the choice type to choice values.

Each choice value should explicitly specify 'bool' or 'tristate',
as all the Kconfig files already

kconfig: do not imply the type of choice value

Do not feed back the choice type to choice values.

Each choice value should explicitly specify 'bool' or 'tristate',
as all the Kconfig files already do. If the type were missing,
"config symbol defined without type" would be shown.

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

show more ...

kconfig: split list_head into a separate header

The struct list_head is often embedded in other structures, while other
code is used in C functions.

By separating struct list_head into its own head

kconfig: split list_head into a separate header

The struct list_head is often embedded in other structures, while other
code is used in C functions.

By separating struct list_head into its own header, other headers are no
longer required to include the entire list.h.

This is similar to the kernel space, where struct list_head is defined
in <linux/types.h> instead of <linux/list.h>.

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

show more ...

kconfig: change file_lookup() to return the file name

Currently, file_lookup() returns a pointer to (struct file), but the
callers use only file->name.

Make it return the ->name member directly.

T

kconfig: change file_lookup() to return the file name

Currently, file_lookup() returns a pointer to (struct file), but the
callers use only file->name.

Make it return the ->name member directly.

This adjustment encapsulates struct file and file_list as internal
implementation.

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

show more ...

kconfig: move the file and lineno in struct file to struct buffer

struct file has two link nodes, 'next' and 'parent'.

The former is used to link files in the 'file_list' linked list,
which manages

kconfig: move the file and lineno in struct file to struct buffer

struct file has two link nodes, 'next' and 'parent'.

The former is used to link files in the 'file_list' linked list,
which manages the list of Kconfig files seen so far.

The latter is used to link files in the 'current_file' linked list,
which manages the inclusion ("source") tree.

The latter should be tracked together with the lexer state.

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

show more ...