[U-Boot] [RFC PATCH 1/7] fpga: CONFIG_SYS_FPGA_PROG_FEEDBACK -> CONFIG_FPGA_PROG_FEEDBACK

Michal Simek michal.simek at xilinx.com
Fri Nov 25 07:57:23 CET 2016


On 25.11.2016 00:57, Chris Packham wrote:
> (dropped addresses that we're bouncing from Cc, hope I got Jagans new
> address right).
> 
> On Thu, Nov 24, 2016 at 1:09 AM, Michal Simek <michal.simek at xilinx.com> wrote:
>> On 22.11.2016 09:48, Chris Packham wrote:
>>> Prepare for move to Kconfig by removing "SYS" from the existing macros.
>>>
>>> Signed-off-by: Chris Packham <judge.packham at gmail.com>
>>> ---
>>
>> This is breaking buildman. You should introduce  Kconfig option in first
>> patch and than this one.
>>
>> [u-boot]$ ./tools/buildman/buildman  apf27 -c 2
>> boards.cfg is up to date. Nothing to do.
>> Building current source for 1 boards (1 thread, 8 jobs per thread)
>>        arm:  +   apf27           )
>> +comm: file 2 is not in sorted order
>> +Error: You must add new CONFIG options using Kconfig
>> +The following new ad-hoc CONFIG options were detected:
>> +CONFIG_FPGA_PROG_FEEDBACK
>> +
>> +Please add these via Kconfig instead. Find a suitable Kconfig
>> +file and add a 'config' or 'menuconfig' option.
>> +make[1]: *** [all] Error 1
>> +make: *** [sub-make] Error 2
>>     0    0    1 /1      apf27
> 
> So I agree that this should probably be closer to the other two
> patches. But won't I have the same problem either way. Unless I squash
> this with "Move FPGA_PROG_FEEDBACK to defconfig" which I can do Is
> that acceptable to everyone.

you shouldn't break buildman.
You don't need to squash patches - there is no reason for that.
Add option to Kconfig in the first patch. Then convert macros in the
second patch and then move option from configs to defconfig in third patch.
This way will keep buildman happy.

Thanks,
Michal



More information about the U-Boot mailing list