summaryrefslogtreecommitdiff
path: root/scripts/kconfig/tests/choice_value_with_m_dep
AgeCommit message (Collapse)Author
2024-07-16kconfig: remove tristate choice supportMasahiro Yamada
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>
2021-04-14kconfig: change "modules" from sub-option to first-level attributeMasahiro Yamada
Now "modules" is the only member of the "option" property. Remove "option", and move "modules" to the top level property. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2018-12-28kconfig: convert to SPDX License IdentifierMasahiro Yamada
All files in lxdialog/ are licensed under GPL-2.0+, and the rest are under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/. Documentation/process/license-rules.rst does not suggest anything about the flex/bison files. Because flex does not accept the C++ comment style at the very top of a file, I used the C style for zconf.l, and so for zconf.y for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kconfig: tests: check visibility of tristate choice values in y choiceMasahiro Yamada
If tristate choice values depend on symbols set to 'm', they should be hidden when the choice containing them is changed from 'm' to 'y' (i.e. exclusive choice). This issue was fixed by commit fa64e5f6a35e ("kconfig/symbol.c: handle choice_values that depend on 'm' symbols"). Add a test case to avoid regression. For the input in this unit test, there is a room for argument if "# CONFIG_CHOICE1 is not set" should be written to the .config file. After commit fa64e5f6a35e, this line was written to the .config file. With commit cb67ab2cd2b8 ("kconfig: do not write choice values when their dependency becomes n"), it is not written now. In this test, "# CONFIG_CHOICE1 is not set" is don't care. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>