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

[Scott Wood <scottwood@freescale.com>]

On Tue, 2015-09-01 at 22:04 -0500, York Sun wrote:
> On 09/01/2015 09:48 PM, Simon Glass wrote:
> > Hi Scott,
> > 
> > On 31 August 2015 at 21:16, Scott Wood <scottwood@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@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@freescale.com>
> > > > > Cc: Kumar Gala <galak@kernel.crashing.org>
> > > > > Cc: Simon Glass <sjg@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?

There is still a warning with this patch applied.

>  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.

That doesn't really apply to errors that happen when loading a kernel...

-Scott