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

[Albert ARIBAUD]

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?

> Regards..
> Prafulla . .

Amicalement,
-- 
Albert.