All of lore.kernel.org
 help / color / mirror / Atom feed
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
> > 

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