From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: "Rick Chen" <rick@andestech.com>, Leo <ycliang@andestech.com>,
"Thomas Fitzsimmons" <fitzsim@fitzsim.org>,
"Simon Glass" <sjg@chromium.org>, "Bin Meng" <bmeng.cn@gmail.com>,
"Marek Behún" <marek.behun@nic.cz>,
"Green Wan" <green.wan@sifive.com>,
"Sean Anderson" <seanga2@gmail.com>, "Lukas Auer" <lukas@auer.io>,
"Brad Kim" <brad.kim@semifive.com>,
"Zong Li" <zong.li@sifive.com>,
"David Abdurachmanov" <david.abdurachmanov@sifive.com>,
"Dimitri John Ledkov" <dimitri.ledkov@canonical.com>,
u-boot@lists.denx.de, trini@konsulko.com
Subject: Re: [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE
Date: Fri, 24 Sep 2021 19:46:04 +0300 [thread overview]
Message-ID: <YU4AzNwQZwHxmPgu@enceladus> (raw)
In-Reply-To: <47893238-a216-1ae4-0af0-e9bf340798a8@canonical.com>
On Fri, Sep 24, 2021 at 04:46:58PM +0200, Heinrich Schuchardt wrote:
>
>
> On 9/24/21 3:10 PM, Ilias Apalodimas wrote:
> > At some point back in 2018 prior_stage_fdt_address and OF_PRIOR_STAGE got
> > introduced, in order to support a DTB handed over by an earlier stage boot
> > loader. However we have another option in the Kconfig (OF_BOARD) which has
> > identical semantics.
> >
> > A good example of this is RISC-V boards which during their startup,
> > pick up the DTB from a1 and copy it in their private gd_t. Apart from that
> > they also copy it to prior_stage_fdt_address, if the Kconfig option is
> > selected, which seems unnecessary(??).
> >
> > This is mostly an RFC, trying to figure out if I am missing some subtle
> > functionality, which would justify having 2 Kconfig options doing similar
> > things present.
> >
> > - Should we do this?
> > - Doesn't OF_BOARD and OF_PRIOR_STAGE practically mean "Someone else is
> > going to pass me my DTB". Why should we care if that someone is a prior
> > bootloader or runtime memory generated on the fly by U-Boot? It all
> > boils down to having a *board* specific callback for that.
> > - RISC-V binman should get rid of the option as well if we decide to go
> > though with this (but I have no idea what RISC-V expects there).
>
> Just replace CONFIG_OF_PRIOR_STAGE by CONFIG_OF_BOARD.
Ah thanks!
>
> > - return (ulong *)gd->arch.firmware_fdt_addr;
[...]
> > - else
> > - return (ulong *)&_end;
> > - }
> > + if (gd->arch.firmware_fdt_addr)
> > + return (ulong *)gd->arch.firmware_fdt_addr;
>
> (ulong *) makes no sense here. (void *) would be more adequate.
>
Yea I preserved what was already in there, since I thought that was gonna
require a different patch to fix. But Since I'll be moving these lines
away I might as well fix it.
> > # elif defined(CONFIG_OF_PRIOR_STAGE)
[...]
> > + /*
> > + * obsolete don't use this on newer boards. Prefer CONFIG_OF_BOARD
> > + * instead
> > + */
>
> This comment should be in Kconfig.
I'll add it on both. The point is prevent people from doing a similar
thing again, even if I miss the mail on the list!
Cheers
/Ilias
>
> Best regards
>
> Heinrich
>
> > gd->fdt_blob = (void *)(uintptr_t)prior_stage_fdt_address;
> > # endif
> > # ifndef CONFIG_SPL_BUILD
> >
prev parent reply other threads:[~2021-09-24 16:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 13:10 [PATCH 1/1 RFC] treewide: Deprecate OF_PRIOR_STAGE Ilias Apalodimas
2021-09-24 13:12 ` Ilias Apalodimas
2021-09-25 17:01 ` Mark Kettenis
2021-09-25 17:49 ` Ilias Apalodimas
2021-09-26 15:54 ` Simon Glass
2021-09-24 13:57 ` Simon Glass
2021-09-24 14:49 ` Ilias Apalodimas
2021-09-24 16:07 ` Simon Glass
2021-10-13 16:26 ` Thomas Fitzsimmons
2021-10-13 16:53 ` Ilias Apalodimas
2021-10-13 16:58 ` Simon Glass
2021-10-13 17:36 ` Thomas Fitzsimmons
2021-10-13 17:58 ` Tom Rini
2021-10-15 16:19 ` Thomas Fitzsimmons
2021-10-24 19:54 ` Simon Glass
2021-10-13 18:05 ` Simon Glass
2021-09-25 17:27 ` Mark Kettenis
2021-09-26 15:53 ` Simon Glass
2021-10-13 16:22 ` Thomas Fitzsimmons
2021-10-13 16:58 ` Simon Glass
2021-09-24 14:46 ` Heinrich Schuchardt
2021-09-24 16:46 ` Ilias Apalodimas [this message]
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=YU4AzNwQZwHxmPgu@enceladus \
--to=ilias.apalodimas@linaro.org \
--cc=bmeng.cn@gmail.com \
--cc=brad.kim@semifive.com \
--cc=david.abdurachmanov@sifive.com \
--cc=dimitri.ledkov@canonical.com \
--cc=fitzsim@fitzsim.org \
--cc=green.wan@sifive.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=lukas@auer.io \
--cc=marek.behun@nic.cz \
--cc=rick@andestech.com \
--cc=seanga2@gmail.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=ycliang@andestech.com \
--cc=zong.li@sifive.com \
/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