2018-03-03 18:34 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>: > On Fri, Mar 2, 2018 at 10:29 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote: >> >> >> On Fri, Mar 2, 2018, 3:14 AM Ulf Magnusson <ulfali...@gmail.com> wrote: >>> >>> On Fri, Mar 2, 2018 at 5:31 AM, Masahiro Yamada >>> > This is complicated usage, but it is still used in the real world; >>> > drivers/usb/gadget/legacy/Kconfig is source'd in a choice context, >>> > then creates a sub-choice in it. >>> >>> That file is the only one that does all that weird choice stuff btw. >>> >>> It's as if it was written to make use of as much obscure Kconfig stuff >>> as possible. :P >> >> >> Can't we just use another way to describe this requirement on this file, >> with the trade-off of simplifying kconfig semantics? >> >> Luis > > I don't think changing how drivers/usb/gadget/legacy/Kconfig does > things would allow for any simplifications, unfortunately (except to > get rid of the fix tested by this patch, maybe).
We could also revert 3b9a19e08960e5cd. :) > Being able to have non-choice-value symbols and choices in choices is > a side effect of automatic submenu creation. Symbols and choices that > depend on the symbol before them end up in a submenu, and only the > top-level symbols in the choice are marked as choice value symbols. > > I always wondered whether that was an intended feature or just > something people discovered works (it seems to work anyway...). It > feels pretty iffy to have cosmetic submenus affect behavior like that, > but playing devil's advocate, it kinda makes sense to put symbols > close to the symbols they depend on if you can get away with it. > I am happy to drop this test if removing the seem-to-work feature will clean up the code. Now I am accumulating test cases. -- Best Regards Masahiro Yamada