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: Tue, 1 Sep 2015 22:14:16 -0500 [thread overview]
Message-ID: <1441163656.4966.148.camel@freescale.com> (raw)
In-Reply-To: <CAPnjgZ1GMANHL__yC1dHUVGDMrAvacf_3hOWYhq3EvAVsq9jyw@mail.gmail.com>
On Tue, 2015-09-01 at 21:10 -0600, Simon Glass wrote:
> Hi Scott,
>
> On 1 September 2015 at 21:00, Scott Wood <scottwood@freescale.com> wrote:
> > On Tue, 2015-09-01 at 20:48 -0600, 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?
> >
> > If booting results in a hang, then you're no worse off than the current
> >
> > situation. Either way, the user sees a message that indicates the
> > problem.
> >
> > > 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.
> >
> > It seems excessive... Config options aren't free, from a maintenance
> >
> > perspective, and I have a hard time imagining a scenario where proceeding
> > to
> >
> > boot causes a real problem.
> >
> > Also, from a consistency perspective:
> > - The OF_STDOUT_PATH version doesn't cause a panic if the destination
> > path
> > doesn't exist.
> > - None of the callers of fdt_status_<foo>_by_alias() panic if the alias
> > is
> > not found.
> > - do_fixup_by_path() doesn't panic if the node is not found.
> > - Neither does do_fixup_by_compatible().
> > - Neither does fdt_fixup_ethernet().
>
> Yes this code needs cleaning up.
I wasn't citing them as problems. :-P
> The particular problem you have is that there are no aliases, right?
> How about returning 0 from fdt_fixup_stdout() in that case? Then you
> will not affect the behaviour of other boards which perhaps do have
> /aliases but do not have space in their tree for the fdt_setprop().
That would be fine.
-Scott
next prev parent reply other threads:[~2015-09-02 3:14 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
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 [this message]
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=1441163656.4966.148.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.