Dirk Gouders <dirk@xxxxxxxxxxx> writes: > 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. Apologies if this sounded rude (I am not a native speaker). What I had in mind was that as far as I remember this patch was posted at the time when Yann changed his interests and therefore it probably now needs Michals attention. 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
