[U-Boot] [PATCH 00/42] Kconfig: Move CONFIG_SPL_..._SUPPORT to Kconfig

[Simon Glass]

Hi Heiko,

On 24 August 2016 at 22:30, Heiko Schocher <hs at denx.de> wrote:
> Hello Simon,
>
>
> Am 24.08.2016 um 18:51 schrieb Simon Glass:
>>
>> This series moves all the CONFIG_SPL_..._SUPPORT options to Kconfig and
>> fixes up existing boards to continue to build.
>
>>
>>
>> It also adds a few small but useful features to moveconfig.
>>
>> There is existing work going on in this area, so some of these patches may
>> be superseded. It has taken me a while to get this building cleanly. But I
>> have run out of time so want to get this out.
>>
>> As mentioned on a recent thread [1] there is some confusion about whether
>> an
>> option means enabling driver support or media support. Andrew's recent
>> series seems like a good vehicle to tidy that up. But I hope this series
>> will make it easier.
>>
>> There are a few strange features of this conversion. The main difficulty
>> is
>> that some PowerPC boards do things like this in their board config file:
>>
>>   #ifdef CONFIG_TPL_BUILD
>>   #define CONFIG_SPL_SERIAL_SUPPORT
>>   #define CONFIG_SPL_ENV_SUPPORT
>>   #else
>>   #define CONFIG_SPL_SERIAL_SUPPORT
>>   #endif
>>
>> This means that TPL reuses the SPL options. We can't support this in
>> Kconfig
>> so I have added a small number of CONFIG_TPL_xxx_SUPPORT options to cope
>> with this. This made the conversion more painful than it should have been.
>>
>> A related issue is boards using a common header file and setting options
>> only
>> for SPL:
>>
>>   #ifdef CONFIG_SPL_BUILD
>>   #define CONFIG_SPL_SERIAL_SUPPORT
>>   #endif
>>
>> This is not noticed by moveconfig so we have to clean it up manually. Also
>> there are a few incorrect things where Kconfig options are set with
>> #define:
>>
>>   #ifdef CONFIG_SPL_BUILD
>>   #define CONFIG_SPL_DM
>>   #endif
>>
>> Finally, many defconfig files are not ordered correctly, resulting in
>> larger
>> patches than we might like. It would be great to have a solution for this,
>> perhaps with buildman providing a warning. But it might slow down
>> development.
>>
>> The series is fully build-tested (for bisectability) and causes no
>> failures
>> for the boards that already pass. The following boards fail for me at
>> present on mainline (which I have not yet looked at):
>
>
> Thanks!
>
> Hmm... may you want to check, if your patchserie does not
> break any existing board? I wrote a tbot testcase for this, see:
>
> http://lists.denx.de/pipermail/u-boot/2016-June/258119.html

Yes that sounds like a good idea. I have spent quite a few hours
ensuring that the series breaks no boards (and bisectability) but not
yet binary compatibility.

At present buildman -K can provide information about config changes,
but it would be more useful if it ignored the difference between
defining an option to '1' and defining it to 'y'.

Regards,
Simon