Re: [PATCH v3] kconfig/symbol.c: handle choice_values that depend on 'm' symbols

From: Dirk Gouders <dirk@gouders.net>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Michal Marek <mmarek@suse.cz>,
	linux-kbuild@vger.kernel.org, Felipe Balbi <balbi@ti.com>,
	USB list <linux-usb@vger.kernel.org>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH v3] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
Date: Thu, 07 Nov 2013 15:02:01 +0100	[thread overview]
Message-ID: <ghr4asl38m.fsf@lena.gouders.net> (raw)
In-Reply-To: <20131106185900.GA3482@free.fr> (Yann E. MORIN's message of "Wed, 6 Nov 2013 19:59:00 +0100")

"Yann E. MORIN" <yann.morin.1998@free.fr> writes:

> Dirk, All,
>
> On 2013-11-06 15:43 +0100, Dirk Gouders spake thusly:
>> "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
> [--SNIP--]
>> > It seems I'm missing something here.
> [--SNIP--]
>> Yes, but obviously, I did not describe it very clearly.  The steps to
>> reproduce the problem are:
>> 
>>      $ ./scripts/kconfig/mconf test.in
>>        --> change c0 and c1 to 'm'        # This is the missing part!
>
> Aha! Gotcha. Thanks.
>
>> I spontaneously planned to answer with a modified config file with
>> default values 'm' specified for 'c0' and 'c1' (complete file below) but
>> I noticed that my latest patch does not help in that case.  The first
>> patch that modifies sym_calc_value() would handle it nicely but the
>> latter one that modifies sym_calc_visibility() does not.  The
>> combination also does not work, because sym_calc_visibility() influences
>> sym_calc_value().
>> 
>> So, I have to say that I am no longer really satisfied with the patch.
>> It fixes the reported problem but I think it should fix related
>> obvious problems as well (see config below).  I'd prefer I take some
>> more time and try to find a more sensible fix.
>
> Please, one patch to fix one bug.
>
> It does not matter if you need to touch the same part of the code, but
> please keep fixes for different bugs, separate (unless of course, the
> bugs are just different manifestations of the same deficiency in the
> code).

I understand.  I will send a v4 with a clearer description of the steps
needed to trigger the problem and also the added Tested-by: line, in
case you see a need for it.

The other two problems I mentioned are concerning default values of
tristate choices and I am quite confident that those fixes will touch
other parts of the code.

Dirk