[U-Boot] [PATCH V7 0/4] Add disk support to orion5x and edminiv2

[Prafulla Wadaskar]

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr] 
> Sent: Friday, August 06, 2010 12:39 PM
> To: Prafulla Wadaskar
> Cc: Wolfgang Denk; u-boot at lists.denx.de; Ashish Karkare; 
> Prabhanjan Sarnaik
> Subject: Re: [PATCH V7 0/4] Add disk support to orion5x and edminiv2
> 
> Le 05/08/2010 20:37, Prafulla Wadaskar a écrit :
> >
> >
> >> -----Original Message-----
> >> From: u-boot-bounces at lists.denx.de
> >> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Wolfgang Denk
> >> Sent: Thursday, August 05, 2010 11:55 PM
> >> To: Albert ARIBAUD
> >> Cc: u-boot at lists.denx.de
> >> Subject: Re: [U-Boot] [PATCH V7 0/4] Add disk support to
> >> orion5x and edminiv2
> >>
> >> Dear Albert ARIBAUD,
> >>
> >> In message<4C5AD4F7.2030604 at free.fr>  you wrote:
> >>>
> >>> As for the configs, some u-boot boards do commonalize, see
> >> for instance
> >>> include/configs/spear*.h. That makes sense because there 
> is a board
> >>> family, with a common HW design and common external components.
> >>
> >> This is not actually a prerequisite. You can create a 
> common look and
> >> feel across completely different boards and architectures.
> >>
> >> For example, include/configs/amcc-common.h provides a 
> common look and
> >> feel for all boards by one specific vendor.
> >
> > That's good idea to generate mv-common.h to abstract 
> Marvell (kirkwood+orion
> > specific )common definitions across the boards
> 
> Why not? The only drawback would be that some board would 
> want to use a 
> config different from what the common config has set (e.g., an Orion 
> board with no MVSATAHC) but even then, the board config file would 
> simply not include the common config, or include it and undefine or 
> redefine some config elements.
> 
> Two (independant) comments:
> 
> 1. If abstracting SoC configuration (which I'm fine with), maybe it 
> would make more sense to abstract by SoC (i.e., kirkwood-common.h, 
> orion5x-common.h...) -- or even by IP (i.e. mvgbe-common.h, 
> mvsata-common.h...) rather than by "commonality".
> 
> 2. Would it be worthwhile, from a readability/maintenability 
> standpoint, 
> to generalize the idea of SoC- and board-specific configs, 
> and thus have 
> board-specific includes in one directory and SoC-specific includes in 
> another?

Any System = f(board, soc).
We have board configs header file in place.
Just having soc-config header file would be enough,
We should have <asm/arch/config.h> included within board config file.
Any unwanted stuff can be undefed below it.

Regards..
Prafulla . .