aboutsummaryrefslogtreecommitdiff
path: root/scripts/kconfig (follow)
Commit message (Collapse)AuthorAgeFilesLines
* scripts: kconfig: merge_config: config files: add a trailing newlineAnders Roxell2024-08-061-0/+2
| | | | | | | | | | | | | | | | | | | | | When merging files without trailing newlines at the end of the file, two config fragments end up at the same row if file1.config doens't have a trailing newline at the end of the file. file1.config "CONFIG_1=y" file2.config "CONFIG_2=y" ./scripts/kconfig/merge_config.sh -m .config file1.config file2.config This will generate a .config looking like this. cat .config ... CONFIG_1=yCONFIG_2=y" Making sure so we add a newline at the end of every config file that is passed into the script. Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kbuild: move some helper headers from scripts/kconfig/ to scripts/include/Masahiro Yamada2024-07-2113-395/+11
| | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: recursive checks drop file/linenoHONG Yifan2024-07-202-48/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <elsk@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove 'e1' and 'e2' macros from expression deduplicationMasahiro Yamada2024-07-201-52/+42
| | | | | | | | | | | | | | I do not think the macros 'e1' and 'e2' are readable. The statement: e1 = expr_alloc_symbol(...); affects the caller's variable, but this is not sufficiently clear from the code. Remove the macros. No functional change intended. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove SYMBOL_CHOICEVAL flagMasahiro Yamada2024-07-165-11/+8
| | | | | | | This flag is unneeded because a choice member can be detected by other means. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: add const qualifiers to several function argumentsMasahiro Yamada2024-07-168-36/+40
| | | | | | Clarify that the given structures are not modified. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: call expr_eliminate_yn() at least once in expr_eliminate_dups()Masahiro Yamada2024-07-161-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kconfig simplifies expressions, but redundant '&&' and '||' operators involving constant symbols 'y' and 'n' are sometimes trimmed and sometimes not. [Test Code] config DEP def_bool y config A bool "A" depends on DEP && y config B bool "B" depends on DEP && y && y [Result] $ make helpnewconfig [ snip ] ----- There is no help available for this option. Symbol: A [=n] Type : bool Defined at Kconfig:4 Prompt: A Depends on: DEP [=y] && y [=y] Location: -> A (A [=n]) ----- ----- There is no help available for this option. Symbol: B [=n] Type : bool Defined at Kconfig:8 Prompt: B Depends on: DEP [=y] Location: -> B (B [=n]) ----- The dependency for A, 'DEP && y', remains as-is, while that for B, 'DEP && y && y', has been reduced to 'DEP'. Currently, expr_eliminate_dups() calls expr_eliminate_yn() only when trans_count != 0, in other words, only when expr_eliminate_dups1() has trimmed at least one leaf. It fails to trim a single '&& y', etc. To fix this inconsistent behavior, expr_eliminate_yn() should be called at least once even if no leaf has been trimmed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: refactor error messages in sym_check_print_recursive()Masahiro Yamada2024-07-161-9/+9
| | | | | | | | | | | | | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: improve error message for recursive dependency in choiceMasahiro Yamada2024-07-161-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: improve error message for dependency between choice membersMasahiro Yamada2024-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: fix conditional prompt behavior for choiceMasahiro Yamada2024-07-162-36/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: remove E_LIST expression typeMasahiro Yamada2024-07-163-18/+2
| | | | | | | | | E_LIST was preveously used to form an expression tree consisting of choice members. It is no longer used. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove P_CHOICE propertyMasahiro Yamada2024-07-166-37/+3
| | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: use sym_get_choice_menu() in sym_check_deps()Masahiro Yamada2024-07-161-4/+4
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: use sym_get_choice_menu() in sym_check_choice_deps()Masahiro Yamada2024-07-161-3/+7
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: use sym_get_choice_menu() in sym_check_print_recursive()Masahiro Yamada2024-07-161-2/+4
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: remove expr_list_for_each_sym() macroMasahiro Yamada2024-07-161-3/+0
| | | | | | All users of this macro have been converted. Remove it. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: use menu_list_for_each_sym() in sym_choice_default()Masahiro Yamada2024-07-161-5/+4
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: change sym_choice_default() to take the choice menuMasahiro Yamada2024-07-163-6/+6
| | | | | | Change the argument of sym_choice_default() to ease further cleanups. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove conf_unsaved in conf_read_simple()Masahiro Yamada2024-07-161-3/+2
| | | | | | This variable is unnecessary. Call conf_set_changed(true) directly. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove sym_get_choice_value()Masahiro Yamada2024-07-166-21/+11
| | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: refactor choice value calculationMasahiro Yamada2024-07-167-197/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: import list_move(_tail) and list_for_each_entry_reverse macrosMasahiro Yamada2024-07-161-0/+53
| | | | | | | | Import more macros from include/linux/list.h. These will be used in the next commit. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remember the current choice while parsing the choice blockMasahiro Yamada2024-07-161-6/+4
| | | | | | | Instead of the boolean flag, it will be more useful to remember the current choice being parsed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: introduce choice_set_value() helperMasahiro Yamada2024-07-165-22/+47
| | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: add fallthrough comments to expr_compare_type()Masahiro Yamada2024-07-161-0/+5
| | | | | | Clarify the missing 'break' is intentional. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unneeded code in expr_compare_type()Masahiro Yamada2024-07-161-4/+1
| | | | | | | | | | | The condition (t2 == 0) never becomes true because the zero value (i.e., E_NONE) is only used as a dummy type for prevtoken. It can be passed to t1, but not to t2. The caller of this function only checks expr_compare_type() > 0. Therefore, the distinction between 0 and -1 is unnecessary. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: add -e and -u options to *conf-cfg.sh scriptsMasahiro Yamada2024-07-164-0/+8
| | | | | | | | | | | | | | Set -e to make these scripts fail on the first error. Set -u because these scripts are invoked by Makefile, and do not work properly without necessary variables defined. Both options are described in POSIX. [1] [1]: https://pubs.opengroup.org/onlinepubs/009604499/utilities/set.html Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: refactor conf_write_defconfig() to reduce indentation levelMasahiro Yamada2024-07-161-25/+22
| | | | | | | | | | Reduce the indentation level by continue'ing the loop earlier if (!sym || sym_is_choice(sym)). No functional change intended. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: refactor conf_set_all_new_symbols() to reduce indentation levelMasahiro Yamada2024-07-161-31/+30
| | | | | | | | | | | | | The outer switch statement can be avoided by continue'ing earlier the loop when the symbol type is neither S_BOOLEAN nor S_TRISTATE. Remove it to reduce the indentation level by one. In addition, avoid the repetition of sym->def[S_DEF_USER].tri. No functional change intended. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: remove tristate choice supportMasahiro Yamada2024-07-1627-315/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/20240427104231.2728905-1-masahiroy@kernel.org/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
* kconfig: pass new conf_changed value to the callbackMasahiro Yamada2024-07-165-14/+11
| | | | | | | | | | | Commit ee06a3ef7e3c ("kconfig: Update config changed flag before calling callback") pointed out that conf_updated flag must be updated _before_ calling the callback, which needs to know the new value. Given that, it makes sense to directly pass the new value to the callback. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: gconf: move conf_changed() definition upMasahiro Yamada2024-07-161-8/+7
| | | | | | | Define conf_changed() before its call site to remove the forward declaration. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: gconf: remove unnecessary forward declarationsMasahiro Yamada2024-07-161-2/+0
| | | | | | These are defined before their call sites. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: qconf: remove initial call to conf_changed()Masahiro Yamada2024-07-161-3/+3
| | | | | | | | | | | If any CONFIG option is changed while loading the .config file, conf_read() calls conf_set_changed(true) and then the conf_changed() callback. With conf_read() moved after window initialization, the explicit conf_changed() call can be removed. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove wrong expr_trans_bool()Masahiro Yamada2024-06-063-32/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <masahiroy@kernel.org> Acked-by: Randy Dunlap <rdunlap@infradead.org>
* kconfig: gconf: give a proper initial state to the Save buttonMasahiro Yamada2024-06-061-1/+2
| | | | | | | | | | | Currently, the initial state of the "Save" button is always active. If none of the CONFIG options are changed while loading the .config file, the "Save" button should be greyed out. This can be fixed by calling conf_read() after widget initialization. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unneeded code for user-supplied values being out of rangeMasahiro Yamada2024-06-061-13/+0
| | | | | | | | | | | This is a leftover from commit ce1fc9345a59 ("kconfig: do not clear SYMBOL_DEF_USER when the value is out of range"). This code is now redundant because if a user-supplied value is out of range, the value adjusted by sym_validate_range() differs, and conf_unsaved has already been incremented a few lines above. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove redundant check in expr_join_or()Masahiro Yamada2024-05-291-1/+1
| | | | | | | | | | The check for 'sym1 == sym2' is redundant here because it has already been done a few lines above: if (sym1 != sym2) return NULL; Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: fix comparison to constant symbols, 'm', 'n'Masahiro Yamada2024-05-291-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, comparisons to 'm' or 'n' result in incorrect output. [Test Code] config MODULES def_bool y modules config A def_tristate m config B def_bool A > n CONFIG_B is unset, while CONFIG_B=y is expected. The reason for the issue is because Kconfig compares the tristate values as strings. Currently, the .type fields in the constant symbol definitions, symbol_{yes,mod,no} are unspecified, i.e., S_UNKNOWN. When expr_calc_value() evaluates 'A > n', it checks the types of 'A' and 'n' to determine how to compare them. The left-hand side, 'A', is a tristate symbol with a value of 'm', which corresponds to a numeric value of 1. (Internally, 'y', 'm', and 'n' are represented as 2, 1, and 0, respectively.) The right-hand side, 'n', has an unknown type, so it is treated as the string "n" during the comparison. expr_calc_value() compares two values numerically only when both can have numeric values. Otherwise, they are compared as strings. symbol numeric value ASCII code ------------------------------------- y 2 0x79 m 1 0x6d n 0 0x6e 'm' is greater than 'n' if compared numerically (since 1 is greater than 0), but smaller than 'n' if compared as strings (since the ASCII code 0x6d is smaller than 0x6e). Specifying .type=S_TRISTATE for symbol_{yes,mod,no} fixes the above test code. Doing so, however, would cause a regression to the following test code. [Test Code 2] config MODULES def_bool n modules config A def_tristate n config B def_bool A = m You would get CONFIG_B=y, while CONFIG_B should not be set. The reason is because sym_get_string_value() turns 'm' into 'n' when the module feature is disabled. Consequently, expr_calc_value() evaluates 'A = n' instead of 'A = m'. This oddity has been hidden because the type of 'm' was previously S_UNKNOWN instead of S_TRISTATE. sym_get_string_value() should not tweak the string because the tristate value has already been correctly calculated. There is no reason to return the string "n" where its tristate value is mod. Fixes: 31847b67bec0 ("kconfig: allow use of relations other than (in)equality") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: remove unused expr_is_no()Masahiro Yamada2024-05-291-5/+0
| | | | | | | This has not been used since commit e911503085ae ("Kconfig: Remove bad inference rules expr_eliminate_dups2()"). Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: use sym_get_choice_menu() in sym_check_prop()Masahiro Yamada2024-05-161-4/+2
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: lxdialog: remove initialization with A_NORMALMasahiro Yamada2024-05-141-9/+0
| | | | | | | A_NORMAL is zero, so the attribute is set to the default A_NORMAL without explicit assignment. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: m/nconf: merge two item_add_str() callsMasahiro Yamada2024-05-142-9/+4
| | | | | | Just trivial cleanups. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: m/nconf: remove dead code to display value of bool choiceMasahiro Yamada2024-05-142-29/+14
| | | | | | | | | | | | | | Previously, optional bool choices met the following conditions simultaneously: - sym_is_choice(sym) - sym_is_changeable(sym) - type == S_BOOLEAN It no longer occurs since 6a1215888e23 ("kconfig: remove 'optional' property support"). Remove the dead code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: m/nconf: remove dead code to display children of choice membersMasahiro Yamada2024-05-142-95/+71
| | | | | | | | | | | This code previously displayed child symbols of the selected choice member. Since commit 7e3465f63a0a ("kconfig: do not reparent the menu inside a choice block"), choice members never have child symbols, therefore this is dead code. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: gconf: show checkbox for choice correctlyMasahiro Yamada2024-05-141-7/+5
| | | | | | | | | | | | Currently, bool choices have a checkbox, but tristate choices do not. It is opposite. Bool choices should not have a checkbox, as they are fixed to 'y' since commit 6a1215888e23 ("kconfig: remove 'optional' property support"). Tristate choices, however, should have a checkbox to allow users to toggle the value. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
* kconfig: use menu_list_for_each_sym() in sym_check_choice_deps()Masahiro Yamada2024-05-101-10/+15
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: use sym_get_choice_menu() in conf_write_defconfig()Masahiro Yamada2024-05-101-4/+5
| | | | | | | | | | | | 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 <masahiroy@kernel.org>
* kconfig: add sym_get_choice_menu() helperMasahiro Yamada2024-05-102-0/+36
| | | | | | | | | | | | | | | | | | 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. We can do this without relying on P_CHOICE by checking the parent in the menu structure. Introduce a new helper to retrieve the choice if the given symbol is a choice member. This is intended to replace prop_get_symbol(sym_get_choice_prop()) and deprecate P_CHOICE eventually. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 16:35:35 +0000