caching BLOBLISTT_SPL_HANDOFF (was Re: [PATCH] common/board_f.c: use #ifdefs a little more consistently)

[Rasmus Villemoes]

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