From: York Sun <yorksun@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [Patch v2 1/2] common/board_f: Preserve global data for mpc85xx and mpc86xx
Date: Wed, 30 Apr 2014 17:17:50 -0700 [thread overview]
Message-ID: <536192AE.80300@freescale.com> (raw)
In-Reply-To: <1398903102.24575.240.camel@snotra.buserror.net>
On 04/30/2014 05:11 PM, Scott Wood wrote:
> On Wed, 2014-04-30 at 17:05 -0700, York Sun wrote:
>> On 04/30/2014 05:02 PM, Scott Wood wrote:
>>> On Wed, 2014-04-30 at 17:01 -0700, York Sun wrote:
>>>>>>> BTW, I see x86 also skips "gd = new_gd" in board_init_r(), so I wonder
>>>>>>> what is going on with gd on x86, and whether it makes sense to lump it
>>>>>>> in with CONFIG_SYS_EARLY_GD.
>>>>>>>
>>>>>>
>>>>>> Maybe x86 maintainers can chime in? If we define such macro, it should probably
>>>>>> sit right above board_init_f() so it can be seen easily. There is no other place
>>>>>> it is needed, yet.
>>>>>
>>>>> I was thinking it would be set the same way other CONFIG symbols are
>>>>> set.
>>>>>
>>>>
>>>> That will be in include/common.h for cross-platform macros.
>>>
>>> No, it's in the particular board files (or better, arch/subarch files
>>> included by board files) that need this. The point is to not have a big
>>> ifdef list, rather than to just move the big ifdef list.
>>>
>>
>> I got your idea. You are suggesting to define this macro in each arch which it
>> needs to preserve gd. So we won't have a list. It is neat but may be easy to miss.
>
> It's how other such things are handled. We'd have a giant mess if we
> had lists of targets strewn throughout the codebase.
>
This will be a negative logic,
#ifndef CONFIG_SYS_EARLY_GD
gd_t data;
gd = &data;
zero_global_data();
#endif
York
next prev parent reply other threads:[~2014-05-01 0:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 21:31 [U-Boot] [Patch v2 1/2] common/board_f: Preserve global data for mpc85xx and mpc86xx York Sun
2014-04-30 21:31 ` [U-Boot] [Patch v2 2/2] common/board_f: Fix size variable York Sun
2014-04-30 22:45 ` [U-Boot] [Patch v2 1/2] common/board_f: Preserve global data for mpc85xx and mpc86xx Scott Wood
2014-04-30 22:48 ` York Sun
2014-04-30 22:51 ` Scott Wood
2014-04-30 22:56 ` York Sun
2014-04-30 22:57 ` Scott Wood
2014-04-30 23:40 ` York Sun
2014-04-30 23:44 ` Scott Wood
2014-04-30 23:48 ` York Sun
2014-04-30 23:52 ` Scott Wood
2014-05-01 0:01 ` York Sun
2014-05-01 0:02 ` Scott Wood
2014-05-01 0:05 ` York Sun
2014-05-01 0:11 ` Scott Wood
2014-05-01 0:17 ` York Sun [this message]
2014-05-01 0:19 ` Scott Wood
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=536192AE.80300@freescale.com \
--to=yorksun@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.