Dear Simon Glass, In message <1353100842-20126-1-git-send-email-...@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.
I missed that. Can you please summarize what exactly the problem was, and how this modification is supposed to fix it? > The solution eventually arrived at was to move these fields into a > separate structure, so that global_data has the generic fields, > and within that there is an arch_global_data structure holding the > architecture-specific ones. > > This series makes that change. Assuming this is reasonable, the next > step is to bring back the generic board patches on top of this. This cover letter has a RFC in the subject,. but the following patch series does not. This is actually bad! General comments / questions: - We always attempted to keep global data as small as possible. What happens here appears to be a move in a totally wrong direction. Instead of simplyfiyng it (and moving stuff out of global data), we add more and more complexity to it. That's wrong. We should not do that. - 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. - What exactly is the impact of this code changes on the memory footprint? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'm what passes for a Unix guru in my office. This is a frightening concept. - Lee Ann Goldstein, in <3k55ba$c...@butch.lmsc.lockheed.com> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot