public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.aribaud@free.fr>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V7 0/4] Add disk support to orion5x and edminiv2
Date: Fri, 06 Aug 2010 09:08:53 +0200	[thread overview]
Message-ID: <4C5BB505.60401@free.fr> (raw)
In-Reply-To: <F766E4F80769BD478052FB6533FA745D19A6576D5E@SC-VEXCH4.marvell.com>

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@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.

  reply	other threads:[~2010-08-06  7:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05 12:35 [U-Boot] [PATCH V7 0/4] Add disk support to orion5x and edminiv2 Albert Aribaud
2010-08-05 12:35 ` [U-Boot] [PATCH V7 1/4] ide: add configuration CONFIG_IDE_SWAP_IO Albert Aribaud
2010-08-05 12:35   ` [U-Boot] [PATCH V7 2/4] ide: add mvsata_ide driver Albert Aribaud
2010-08-05 12:35     ` [U-Boot] [PATCH V7 3/4] cmd_ide: add support for orion5x Albert Aribaud
2010-08-05 12:35       ` [U-Boot] [PATCH V7 4/4] edminiv2: add mvsata_ide and cmd_ide support Albert Aribaud
2010-08-05 18:48         ` Prafulla Wadaskar
2010-08-05 18:43       ` [U-Boot] [PATCH V7 3/4] cmd_ide: add support for orion5x Prafulla Wadaskar
2010-08-05 21:28         ` Albert ARIBAUD
2010-08-05 19:09     ` [U-Boot] [PATCH V7 2/4] ide: add mvsata_ide driver Prafulla Wadaskar
2010-08-05 21:29       ` Albert ARIBAUD
2010-08-06  9:38         ` Albert ARIBAUD
2010-08-07  6:39     ` Prafulla Wadaskar
2010-08-07  8:31       ` Albert ARIBAUD
2010-08-05 18:58   ` [U-Boot] [PATCH V7 1/4] ide: add configuration CONFIG_IDE_SWAP_IO Prafulla Wadaskar
2010-08-05 12:42 ` [U-Boot] [PATCH V7 0/4] Add disk support to orion5x and edminiv2 Rogan Dawes
2010-08-05 13:02   ` Wolfgang Denk
2010-08-05 14:11     ` Albert ARIBAUD
2010-08-05 14:28       ` Rogan Dawes
2010-08-05 15:12         ` Albert ARIBAUD
2010-08-05 15:35           ` Rogan Dawes
2010-08-05 18:25           ` Wolfgang Denk
2010-08-05 18:37             ` Prafulla Wadaskar
2010-08-06  7:08               ` Albert ARIBAUD [this message]
2010-08-06  8:18                 ` Prafulla Wadaskar
2010-08-06  9:09                   ` Albert ARIBAUD

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=4C5BB505.60401@free.fr \
    --to=albert.aribaud@free.fr \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox