On Tue, 2013-08-13 at 08:57 +1100, Stephen N Chivers wrote:

Scott Wood [off-list ref] wrote on 08/09/2013 04:07:24 AM:

quoted

From: Scott Wood <redacted>
To: Kumar Gala <redacted>
Cc: Stephen N Chivers <redacted>, <redacted>, 
[off-list ref], Chris Proctor [off-list ref]
Date: 08/09/2013 04:08 AM
Subject: Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for 
Motorola/Emerson MVME5100.

On Thu, 2013-08-08 at 10:30 -0500, Kumar Gala wrote:

quoted

Also, we don't take full defconfigs in the tree, look at 'make 

savedefconfig'

Why does this board need its own defconfig at all?  Just add it to
ppc6xx_defconfig.

The boards firmware as stated above is PPCBug. PPCBug is not Open Firmware
compatible.

There is no U-Boot support for the board.

I'm not sure why that precludes the use of ppc6xx_defconfig...

In ppc6xx_defconfig the e100 network device and NFS support is modular and
that forces the use of an initrd.

OK, then let's enable those in ppc6xx_defconfig.  We do in a lot of the
other defconfigs (such as 85xx and derivatives).

PPCBugs network boot command takes only one file argument and so makes
it difficult to use an initrd.

So the choices are:
        - Providing a defconfig for the board,
        - Building the kernel with the initrd embedded in it,
        - Finding an alternative boot loader,
        - Doing the board support for U-Boot.
The first choice is simple and documents the configuration of the
board without mixing it into ppc6xx_defconfig.

The first choice means your board would get much less build-testing, and
would increase maintenance costs of defconfig changes (and/or lead to
divergence from other defconfigs that doesn't actually have anything to
do with this board or its use cases).

The fifth choice is "add what you need to ppc6xx_defconfig".  Within
reason of course, but I think a common PCI network device and NFS root
support is reasonable.

-Scott