[U-Boot] [PATCH] bootm: Use "panic()" in non-recoverable error conditions

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Kyle,

Le 20/10/2011 22:06, Moffett, Kyle D a ?crit :
> On Oct 20, 2011, at 15:31, Wolfgang Denk wrote:
>> Dear Kyle Moffett,
>> In message<1319134031-28503-1-git-send-email-Kyle.D.Moffett@boeing.com>  you wrote:
>>> All of these errors are various kinds of fatal memory overwrite
>>> conditions and so should be handled by panic().  This fixes a bug in
>>> which the error message might not get all the way out to the serial
>>> console before the system reboots; panic() has a built-in delay after
>>> doing a printf() before calling do_reset().
>>>
>>> This will result in a change in behavior for the 27 board configuration
>>> files which set CONFIG_PANIC_HANG (less than 5% of the total).  They
>>> will now hang in those fatal error conditions instead of trying to
>>> reboot.
>>>
>>> Given that CONFIG_PANIC_HANG is intended to prevent the system from
>>> rebooting after it has encountered an unrecoverable error, this seems to
>>> be the desired behavior for those 27 board configurations.
>>
>> This is your interpretation, but the users and especially the
>> respective board maintainers may think different.  We should at least
>> try and get feedback from them first.
>
> Well, to be fair, the README says this about the config option:
>
>    CONFIG_PANIC_HANG
>
>    Define this variable to stop the system in case of a
>    fatal error, so that you have to reset it manually.
>    This is probably NOT a good idea for an embedded
>    system where you want the system to reboot
>    automatically as fast as possible, but it may be
>    useful during development since you can try to debug
>    the conditions that lead to the situation.
>
> Cheers,
> Kyle Moffett

This is the description for wanting panic() to hang rather than reset; 
but your patch puts panic()s where there were not, doesn't it? And in so 
doing, it changes the behavior of the code.

Amicalement,
-- 
Albert.