Roger Quadros <rogerq@xxxxxx> writes: > On 31/03/16 01:16, Ruslan Bilovol wrote: >> Hi, >> >> On Thu, Mar 31, 2016 at 1:08 AM, Bin Liu <binmlist@xxxxxxxxx> wrote: >>> Hi, >>> >>> On Fri, Aug 15, 2014 at 2:37 AM, Dirk Gouders <dirk@xxxxxxxxxxx> wrote: >>>> Bin Liu <binmlist@xxxxxxxxx> writes: >>>> >>>>> Dirk, >>>>> >>>>> On Thu, Aug 14, 2014 at 1:52 AM, Dirk Gouders <dirk@xxxxxxxxxxx> wrote: >>>>>> Bin Liu <binmlist@xxxxxxxxx> writes: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> On Mon, Nov 18, 2013 at 12:08 PM, Yann E. MORIN <yann.morin.1998@xxxxxxx> wrote: >>>>>>>> Dirk, All, >>>>>>>> >>>>>>>> On 2013-11-07 15:05 +0100, Dirk Gouders spake thusly: >>>>>>>>> If choices consist of choice_values that depend on symbols set to 'm', >>>>>>>>> those choice_values are not set to 'n' if the choice is changed from >>>>>>>>> 'm' to 'y' (in which case only one active choice_value is allowed). >>>>>>>>> Those values are also written to the config file causing modules to be >>>>>>>>> built when they should not. >>>>>>>>> >>>>>>>>> The following config can be used to reproduce and examine the problem; >>>>>>>>> with the frontend of your choice set "Choice 0" and "Choice 1" to 'm', >>>>>>>>> then set "Tristate Choice" to 'y' and save the configuration: >>>>>>>>> >>>>>>>>> config modules >>>>>>>>> boolean modules >>>>>>>>> default y >>>>>>>>> option modules >>>>>>>>> >>>>>>>>> config dependency >>>>>>>>> tristate "Dependency" >>>>>>>>> default m >>>>>>>>> >>>>>>>>> choice >>>>>>>>> prompt "Tristate Choice" >>>>>>>>> default choice0 >>>>>>>>> >>>>>>>>> config choice0 >>>>>>>>> tristate "Choice 0" >>>>>>>>> >>>>>>>>> config choice1 >>>>>>>>> tristate "Choice 1" >>>>>>>>> depends on dependency >>>>>>>>> >>>>>>>>> endchoice >>>>>>>>> >>>>>>>>> This patch sets choice_values' visibility that depend on symbols set >>>>>>>>> to 'm' to 'n' if the corresponding choice is set to 'y'. This makes >>>>>>>>> them disappear from the choice list and will also cause the >>>>>>>>> choice_values' value set to 'n' in sym_calc_value() and as a result >>>>>>>>> they are written as "not set" to the resulting .config file. >>>>>>>>> >>>>>>>>> Reported-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> >>>>>>>>> Signed-off-by: Dirk Gouders <dirk@xxxxxxxxxxx> >>>>>>>>> Tested-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> >>>>>>>> >>>>>>>> Acked-by: "Yann E. MORIN" <yann.morin.1998@xxxxxxx> >>>>>>>> >>>>>>>> It will be in my tree soon. Thanks! >>>>>>> >>>>>>> I don't see this patch in 3.16 but 3.16 does not have the issue any >>>>>>> more. Anyone has an idea how the issue got fixed? I am trying to find >>>>>>> the right patch to backport. >>>>>> >>>>>> With the above sample kconfig I still see the issue. How did you >>>>>> notice the issue got fixed? >>>>> >>>>> I did not pay much attention on the above sample kconfig, but just >>>>> focused on the USB gadget driver kconfig issue initially reported by >>>>> Sebastian. I saw the issue exists in 3.14, but does not in 3.16, >>>>> unless I messed up with my test. I will test 3.16 again some time next >>>>> week. >>>> >>>> Hi Bin, >>>> >>>> I now also re-tested the initially reported steps to reproduce the >>>> issue: >>>> >>>> ------------------------------------------------------------------------ >>>>> in USB gadget menu (that is Device Drivers ---> USB support ---> USB >>>>> Gadget Support ---> USB Gadget Drivers) I can create a configuration >>>>> which is "lost". Here is how to reproduce it: >>>>> >>>>> - first config two gadgets as M: >>>>> <M> USB Gadget Drivers >>>>> <M> Audio Gadget >>>>> <M> Ethernet Gadget >>>>> <M> MIDI Gadget >>>>> >>>>> save config & leave >>>>> >>>>> - now start menu config again and go to the same menu, now select >>>>> built-in: >>>>> <*> USB Gadget Drivers (Ethernet Gadget >>>>> the ethernet gadget is chosen automatically because we can have only >>>>> one gadget selected. >>>>> save config & leave >>>>> >>>>> - step three, go back to the menu and you will see that everything is >>>>> as it was (the <*> is ignored). >>>> ------------------------------------------------------------------------ >>>> >>>> Here, I still see the problem (I was wondering if the issue has been >>>> solved/gone by a kconfig-file modification). >>> >>> This issue was gone since 3.16, but came back again due to commit >>> 1fd6d08 ARM: omap2plus_defconfig: Enable n900 modem as loadable modules. >>> >> >> I can confirm this issue too, faced it on v4.5 (but didn't try v4.6-rc1 yet) >> > > Issue is present on v4.6-rc1 as well and the $subject patch fixes the issue. I would say the issue is present until the code is fixed. Whether it is triggered depends on the Kconfig used. Perhaps, Michal could take a look at the patch that Yann ack'ed, some time ago. Dirk -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
