[U-Boot] [PATCH 2/2] fdt_support: Don't panic if unable to perform stdout fixup

[York Sun]

On 09/01/2015 09:48 PM, Simon Glass wrote:
> Hi Scott,
> 
> On 31 August 2015 at 21:16, Scott Wood <scottwood at freescale.com> wrote:
>> On Mon, 2015-08-31 at 21:13 -0600, Simon Glass wrote:
>>> Hi Scott,
>>>
>>> On 31 August 2015 at 20:11, Scott Wood <scottwood at freescale.com> wrote:
>>>> Currently, using fdt_fixup_stdout() on a device tree that is missing
>>>> the relevant alias results in this:
>>>>
>>>> WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
>>>> ERROR: /chosen node create failed
>>>>  - must RESET the board to recover.
>>>>
>>>> FDT creation failed! hanging...### ERROR ### Please RESET the board ###
>>>>
>>>> There is no reason for this to be a fatal error rather than a warning,
>>>> and removing this allows for a smooth transition on a platform where
>>>> the device tree currently lacks the correct aliases but will have them
>>>> in the future.
>>>
>>> Why do we need this patch - what platform?
>>
>> LS2085A
>>
>>>
>>>>
>>>> Signed-off-by: Scott Wood <scottwood at freescale.com>
>>>> Cc: Kumar Gala <galak at kernel.crashing.org>
>>>> Cc: Simon Glass <sjg at chromium.org>
>>>> ---
>>>> Resent with correct address for Simon Glass.
>>>>
>>>>  common/fdt_support.c | 3 ++-
>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/common/fdt_support.c b/common/fdt_support.c
>>>> index f86365e..6052c77 100644
>>>> --- a/common/fdt_support.c
>>>> +++ b/common/fdt_support.c
>>>> @@ -308,7 +308,8 @@ int fdt_chosen(void *fdt)
>>>>                 }
>>>>         }
>>>>
>>>> -       return fdt_fixup_stdout(fdt, nodeoffset);
>>>> +       fdt_fixup_stdout(fdt, nodeoffset);
>>>
>>> Will some platforms will not boot correctly with this failing? Should
>>> we make your new feature a Kconfig options perhaps? I worry that it
>>> will become the default behaviour and then it will be hard to remove
>>> later.
>>
>> A warning will still be printed.  I'm not sure how "### ERROR ### Please
>> RESET the board ###" is more useful than trying to continue and possibly
>> failing.
> 
> Only that if it indicates a fatal error the board code can at least
> find out about it and deal with it. Perhaps booting will just result
> in a hang?
> 
> I think ignoring errors is fine but here we make it impossible to
> detect a failure. So I think that a Kconfig is the best idea, so we
> can remove it later.

How about a big warning instead? In general, having the message to reset the
board doesn't help much if it is a fatal condition. We have to use external tool
to recover the board. On the other side, if the error is not fatal, continue to
boot may give the user a chance to reflash an update.

York