All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: u-boot@lists.denx.de
Subject: caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently)
Date: Fri, 28 Feb 2020 23:09:04 +0000	[thread overview]
Message-ID: <735f422a-c9fb-8cb3-5cc9-f2facec0d40c@prevas.dk> (raw)
In-Reply-To: <20200228173524.GK18302@bill-the-cat>

On 28/02/2020 18.35, Tom Rini wrote:
> On Fri, Feb 28, 2020 at 05:24:58PM +0000, Rasmus Villemoes wrote:

>> eliminated, and there's not an #ifdef in sight.
> 
> That sounds pretty nice actually.  If you're so inclined I'd like to see
> it.
> 

So I started looking at that, and while it's mostly mechanical, one
quickly hits the case I was worried about, some of the functions
referring to symbols or struct members that are conditionally
defined/declared, so there's no way around guarding such accesses at the
preprocessor level.

Case in point: I'd like to do

--- a/common/board_f.c
+++ b/common/board_f.c
@@ -287,11 +287,9 @@ static int setup_mon_len(void)

 static int setup_spl_handoff(void)
 {
-#if CONFIG_IS_ENABLED(HANDOFF)
        gd->spl_handoff = bloblist_find(BLOBLISTT_SPL_HANDOFF,
                                        sizeof(struct spl_handoff));
        debug("Found SPL hand-off info %p\n", gd->spl_handoff);
-#endif

        return 0;
 }
@@ -886,7 +884,7 @@ static const init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_BLOBLIST
        bloblist_init,
 #endif
-       setup_spl_handoff,
+       CONFIG_IS_ENABLED(HANDOFF) ? setup_spl_handoff : NULL,
        initf_console_record,
 #if defined(CONFIG_HAVE_FSP)
        arch_fsp_init,

but that doesn't work because gd->spl_handoff only exists when
CONFIG_IS_ENABLED(BLOBLIST) && defined(CONFIG_SPL).

Now that particular one seems a bit fishy: Why is it ok to cache the
location of the BLOBLISTT_SPL_HANDOFF blob in gd->spl_handoff? Later in
the init sequence there's a call to reserve_bloblist, and later again
reloc_bloblist. Doesn't that leave gd->spl_handoff stale?

I'd expect that users would always have to look it up via
bloblist_find(). Simon?

Rasmus

  reply	other threads:[~2020-02-28 23:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  8:18 [PATCH] common/board_f.c: use #ifdefs a little more consistently Rasmus Villemoes
2020-02-27 23:40 ` Simon Glass
2020-02-28  8:42   ` Rasmus Villemoes
2020-02-28 15:46     ` Tom Rini
2020-02-28 17:24       ` Rasmus Villemoes
2020-02-28 17:35         ` Tom Rini
2020-02-28 23:09           ` Rasmus Villemoes [this message]
2020-03-02 19:47             ` caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently) Simon Glass
2020-03-02 20:01               ` caching BLOBLISTT_SPL_HANDOFF Rasmus Villemoes
2020-03-04 23:11                 ` Simon Glass

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=735f422a-c9fb-8cb3-5cc9-f2facec0d40c@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --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.