From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xyzzy.farnsworth.org (xyzzy.farnsworth.org [65.39.95.219]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 138C0DF783 for ; Fri, 18 Apr 2008 02:08:20 +1000 (EST) Date: Thu, 17 Apr 2008 09:08:04 -0700 From: Dale Farnsworth To: Sean MacLennan Message-ID: <20080417160804.GA696@farnsworth.org> References: <20080412134831.424480cf@lappy.seanm.ca> <20080413104430.c98244d2.sfr@canb.auug.org.au> <20080412215544.38fa2d0b@lappy.seanm.ca> <20080417115045.7e4e6b1e@lappy.seanm.ca> MIME-Version: 1.0 In-Reply-To: <20080417115045.7e4e6b1e@lappy.seanm.ca> Subject: Re: Warp patches for 2.6.26 Content-Type: text/plain; charset=us-ascii Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Apr 17, 2008 at 11:50:45AM -0400, Sean MacLennan wrote: > On Sat, 12 Apr 2008 20:13:16 -0700 > "Dale Farnsworth" wrote: > > > Each patch needs to be standalone. you need to add a header > > describing what the patch is intended to accomplish. Being more > > descriptive is better than less. Also, as Stephen said, make sure > > that the subject of each email containing a patch is descriptive and > > reasonably unique within the entire kernel. > > Splitting up the patches would be very error prone. I would have to > basically do all the editing by hand. I didn't suggest splitting the patches or further modification of the patches themselves. What I found lacking were the patch descriptions. You need to describe in each patch (commit) commentary exactly what the patch is intended to accomplish, and the rationale behind it. > I also think I am not being clear enough. Basically what is currently > in the mainline is platform code for a Rev A board with minimal FPGA > functionality, since that is what we had at the time. > > These patches, I should probably merge them into one patch, bring the > platform code up to a Rev B board with a more complete FPGA load. (I > say more complete because FPGA loads are never complete ;) > > These patches only affect the Warp. Ignoring the LED and WDT patches, > you have to have all the changes to get a working Rev B. You can't just > put in the DTM changes or just put in the NAND changes. > > I listed 8 changes, but three are for NAND, and four are for DTM. I > could compress them down: > > Updated platform code to support Rev B boards. > * Switched from 64M NOR/64M NAND to 4M NOR/256M NAND. > * Fully functional DTM. > * Added POST information. > * Removed LED function, moved to new LED driver. > > Now, the POST function and the removed LED function could be separate > patches I guess, but it hardly seems worth it. The LED function was > never used except in temporary debug code. > > > For example, instead of "WDT driver", as a minimum something like: > > "[POWERPC] warp: Add WDT driver". > > Ok, that I can do. -Dale