From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from semihalf.com (semihalf.com [206.130.101.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9F291DDE0A for ; Fri, 4 Apr 2008 22:14:47 +1100 (EST) Message-ID: <47F60D5D.5090402@semihalf.com> Date: Fri, 04 Apr 2008 13:13:33 +0200 From: Bartlomiej Sieka MIME-Version: 1.0 To: Grant Likely Subject: Re: Please pull linux-2.6-mpc52xx.git References: <20080317222836.AFA66241A2@gemini.denx.de> <47E938A8.9000103@semihalf.com> <47F22C9A.4050501@semihalf.com> In-Reply-To: <47F22C9A.4050501@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Bartlomiej Sieka wrote: > Hi Grant, > > Grant Likely wrote: >> On Tue, Mar 25, 2008 at 11:38 AM, Bartlomiej Sieka >> wrote: >>> Grant Likely wrote: >>> > The one part that I have a really strong opinion on is that there >>> > should be a full featured mpc5200 defconfig for build testing. >>> Beyond >>> > that (and if ojn can also be appeased) I can probably be >>> convinced. :-) >>> >>> Hi Grant, >>> >>> How to deal with a situation where I need a particular PHY driver from >>> libphy compiled in the kernel for one of the MPC5200 boards? Adding it >>> to mpc5200_defconfig doesn't seem like a right thing to do. >> >> Why not? mpc5200_defconfig is all about compile and runtime testing >> on many platforms to make sure drivers play well together. I have no >> problem adding more drivers to the mpc5200 defconfig. (In fact, I >> encourage it). >> >>> How to >>> convince you (and appease ojn) to accept a patch that adds a >>> board-specific defconfig that only slightly differs from >>> mpc5200_defconfig? :) >> >> I'm thinking 'optimized' defconfigs should go into a subdirectory. > > This requires a change to the top-level Makefile and shepherding this > change upstream. Could we perhaps try to avoid this by having optimized > defconfigs in the form of, for example: > > arch/powerpc/configs/tqm5200_opt_defconfig > arch/powerpc/configs/motionpro_opt_defconfig > > Or, to signify what is the base defconfig: > > arch/powerpc/configs/mpc5200_tqm5200_defconfig > arch/powerpc/configs/mpc5200_motionpro_defconfig > > or even: > > arch/powerpc/configs/mpc5200_opt_tqm5200_defconfig > arch/powerpc/configs/mpc5200_opt_motionpro_defconfig > > Would patch adding an optimized _defconfig along these lines be accepted? Grant, Any thoughts on the above? Regards, Bartlomiej