Hi Tom, Simon, Wolfgang,
On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini trini@ti.com wrote:
On Tue, Nov 20, 2012 at 06:06:30AM -0800, Simon Glass wrote:
Hi Wolfgang,
On Mon, Nov 19, 2012 at 11:25 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message 1353100842-20126-1-git-send-email-sjg@chromium.org you wrote:
The previous generic board series hit a snag in that we needed generic code to access some of the architecture-specific fields in global_data.
[snip]
- The change makes the code less readable. Reading "gd->arch." instead of plain "gd->" is no improvements, but rather vice versa. If we really go this way, this should be improved.
Yes it would be nice. Are you suggesting some sort of macro, or something else?
Wolfgang? "global data, architecture specific goo, ..." reads fine and helpful to me, honestly.
I've mentioned this before - I think gd is being abused. To me, gd should contain only data members that are explicitly required prior to SDRAM being initialised and BSS being available. It has become a bit of a 'well I need this variable everywhere, I'll dump it in gd'.
To be honest, I think gd should only be a temporary structure used to carry specific data through the initialisation process up to the point BSS becomes available. With the 'early malloc' patches in the pipeline, it might even be possible to malloc the gd structure early and then when BSS is available, copy the data into the final global data structure in BSS. I think that would be complicated by functions that need to use gd both before and after BSS becomes available.
Regards,
Graeme