From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 59093DE0E1 for ; Thu, 23 Apr 2009 03:38:29 +1000 (EST) Message-ID: <49EF560F.90208@freescale.com> Date: Wed, 22 Apr 2009 12:38:23 -0500 From: Scott Wood MIME-Version: 1.0 To: Kumar Gala Subject: Re: [PATCH v3] powerpc/85xx: Add P2020DS board support References: <1240371105-18400-1-git-send-email-galak@kernel.crashing.org> <20090422164400.GA9592@ld0162-tx32.am.freescale.net> <6EC8B59D-62C8-4D9B-B548-4833A06F13AB@kernel.crashing.org> <49EF4E27.9020203@freescale.com> <95BA4C47-8B99-4E94-9855-4333BB4A751C@kernel.crashing.org> <49EF50EC.1040608@freescale.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Kumar Gala wrote: > > On Apr 22, 2009, at 12:16 PM, Scott Wood wrote: > >> Kumar Gala wrote: >>> On Apr 22, 2009, at 12:04 PM, Scott Wood wrote: >>>> Kumar Gala wrote: >>>>>> If this has an elbc more recent than 1.0 (looks like it), we should >>>>>> indicate that here. >>>>> that might be the case, but I leave it to u-boot to do that. >>>> >>>> Why? There's no p2020 with an older eLBC, and there's no block >>>> version register. >>> But there might be a p2020 w/a newer eLBC version in the future. >> >> At which point we can add something to u-boot -- but magic SVR tables >> seem a step backward from the dts except where needed to avoid the >> creation of extra dts files. > > I don't see the value of complicating u-boot But complicating u-boot is just what you're suggesting. Put it in the dts, and u-boot has *zero* code to deal with this unless we find ourselves wanting to share the dts with another board rev with a newer chip with a newer elbc. > to have to parse and > "fixup" the compatible instead of just having to prepend to it. > Especially since I don't believe there is anything specific we care > about in the 1.2 version of elbc at this point. If the new elbc is compatible with the current one, then you will still just be prepending. If it is not, then it very likely isn't compatible with 1.0 either, so you'll have to remove fsl,elbc anyway. What "we care about" at this point is irrelevant, given the PITA it would be to change the device trees (or u-boot) that are already in use once we do begin to care. -Scott