On Mon, 7 Jul 2008 07:34:23 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 7, 2008 at 7:18 AM, Josh Boyer <[EMAIL PROTECTED]> wrote: > > On Fri, 4 Jul 2008 00:51:44 -0600 > > "Grant Likely" <[EMAIL PROTECTED]> wrote: > > > >> Anyone had a chance to look at this? I think this could be used to > >> eliminate a lot of the platform specific default targets in > >> arch/powerpc/boot/Makefile by moving them into the defconfigs. Josh, > >> Kumar, what are your thoughts? > > > > So for cases like Kilauea/Haleakala or Bamboo/Yosemite, you would > > specify Yosemite in the bamboo defconfig? Or? > > If they share a defconfig, then yes, that is what I'm thinking about... > > > I actually sort of prefer having a separate defconfig/CONFIG_YOSEMITE > > (as an example) because it's much easier for an end user to figure out > > if the board is supported or not. > > ...however, these don't have to disappear if you prefer them. Right. > > I could be totally misunderstanding the intention of this patch though, > > so I'll stop rambling and wait to see what the use case is. > > Specifically the case I'm thinking of is when a user of a Xilinx FPGA > drops a new .dts file into arch/powerpc/boot/dts (say > 'super-sexy-platform.dts'). However, instead of modifying the > Makefile or always typing 'make simpleImage.super-sexy-platform', then > can add 'simpleImage.super-sexy-platform' to their defconfig which I > can see being easier for someone to get their head around. Yeah, I thought about the Virtex case with the differing bitstreams after I sent out my original question. For purposes like that, this seems like a great fit. For truly discrete boards, I prefer discrete defconfigs. So overall I see value in the patch. If nobody else has objections, then it's fine with me. josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
