[U-Boot] [PATCH 1/2] Kconfig: add CONFIG_BOOTDELAY

[Simon Glass]

Hi Igor,

On 12 October 2015 at 12:52, Igor Grinberg <grinberg at compulab.co.il> wrote:
> Hi Simon,
>
> On 10/09/15 12:36, Simon Glass wrote:
>> Hi Igor,
>>
>> On 8 October 2015 at 20:10, Igor Grinberg <grinberg at compulab.co.il> wrote:
>>> Add CONFIG_BOOTDELAY to the Kconfig.
>>> Default it to 3 seconds according to the majority of configs.
>>>
>>> Signed-off-by: Igor Grinberg <grinberg at compulab.co.il>
>>> Cc: Simon Glass <sjg at chromium.org>
>>> Cc: Masahiro Yamada <yamada.masahiro at socionext.com>
>>> ---
>>>  common/Kconfig | 10 ++++++++++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/common/Kconfig b/common/Kconfig
>>> index d98eb19..e13d255 100644
>>> --- a/common/Kconfig
>>> +++ b/common/Kconfig
>>> @@ -100,6 +100,16 @@ config AUTOBOOT_STOP_STR_SHA256
>>>           string / password matches a values that is encypted via
>>>           a SHA256 hash and saved in the environment.
>>>
>>> +config BOOTDELAY
>>> +       int "Seconds to delay before autobooting"
>>> +       default 3
>>> +       help
>>> +         Delay before automatically booting the default image;
>>> +         set to -1 to disable autoboot.
>>> +         set to -2 to autoboot with no delay and not check for abort
>>> +         (even when CONFIG_ZERO_BOOTDELAY_CHECK is defined).
>>> +         See doc/README.autoboot for additional information.
>>> +
>>>  endmenu
>>>
>>>  comment "Commands"
>>> --
>>> 2.4.9
>>>
>>
>> It's great that you are taking on these difficult ones.
>
> Thanks...
>
>>
>> IMO we should split this config into a few parts:
>>
>> - enabling the boot-delay feature
>> - setting the boot-delay time
>> - whether to allow abort
>> - whether to allow abort even when boot delay is 0
>>
>> The way it is written -2 sounds like a weird case that would be better
>> merged with the last one above.
>
> I completely agree with you. This is indeed the better way, AFAICS.
> Although, I'm not sure I can work on this right now.
> How about having it currently the way above and adjusting it later
> (when one/me has the time to do it)?

I suspect it would be better to wait. The problem is that moving a
broken/painful config to Kconfig is not really a step forward. It just
makes more work for someone later I think. It is probably better to do
it right from the start.

Regards,
Simon