From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] fdt_support: Don't panic if unable to perform stdout fixup
Date: Mon, 31 Aug 2015 22:16:27 -0500 [thread overview]
Message-ID: <1441077387.4966.49.camel@freescale.com> (raw)
In-Reply-To: <CAPnjgZ0od7Umc0H+45-C+gGawXPPhWjJWdBB3gzDb=-=utuOtQ@mail.gmail.com>
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.
-Scott
next prev parent reply other threads:[~2015-09-01 3:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 2:05 [U-Boot] [PATCH 1/2] arm/fsl-ls: Add CONFIG_OF_STDOUT_VIA_ALIAS Scott Wood
2015-09-01 2:05 ` [U-Boot] [PATCH 2/2] fdt_support: Don't panic if unable to perform stdout fixup Scott Wood
2015-09-01 2:11 ` Scott Wood
2015-09-01 3:13 ` Simon Glass
2015-09-01 3:16 ` Scott Wood [this message]
2015-09-02 2:48 ` Simon Glass
2015-09-02 3:00 ` Scott Wood
2015-09-02 3:10 ` Simon Glass
2015-09-02 3:14 ` Scott Wood
2015-09-02 3:04 ` York Sun
2015-09-02 3:06 ` Scott Wood
2015-09-02 3:48 ` [U-Boot] [PATCH v2 2/2] fdt_support: Don't panic if stdout alias is missing Scott Wood
2015-09-02 14:05 ` Simon Glass
2015-10-30 16:12 ` York Sun
2015-10-30 16:11 ` [U-Boot] [PATCH 1/2] arm/fsl-ls: Add CONFIG_OF_STDOUT_VIA_ALIAS York Sun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1441077387.4966.49.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox