From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 27 Aug 2010 16:59:08 -0500 Subject: [U-Boot] [PATCH v4 3/4] mtdparts: add new sub-command "spread" In-Reply-To: <4C78322D.8090205@freescale.com> References: <1278366212-24023-1-git-send-email-bengardiner@nanometrics.ca> <1281386640-26918-4-git-send-email-bengardiner@nanometrics.ca> <20100826211209.GA22539@schlenkerla.am.freescale.net> <4C78322D.8090205@freescale.com> Message-ID: <4C78352C.20008@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 08/27/2010 04:46 PM, Scott Wood wrote: > On 08/27/2010 04:36 PM, Ben Gardiner wrote: >> On Fri, Aug 27, 2010 at 9:51 AM, Ben Gardiner >> wrote: >> I have performed a refactoring but I have reached an impasse: the >> 'mtdparts spread' command is written for mtd devices whereas the >> get_len_incl_bad() function is for NAND devices. I extracted a >> function, mtd_get_len_incl_bad(), to which both the spread_partition >> and nand_utils.c:get_len_incl_bad() function then delegated. > > I figured the NAND code could just call the MTD-ized get_len_incl_bad() > directly. > >> But since a board may have NAND enabled but not MTD_DEVICE (i.e. >> guruplug) I get >> link errors sometimes. > > Grr... Eventually we ought to make NAND depend on MTD_DEVICE. It's 808 > bytes currently in my build, but if we could get rid of/reduce > specialized client code, it could more than make up for it. > > For now, I guess don't worry about sharing the code. Plus, I've got some changes to the NAND command/util code I'm about to send out that touch this -- if sharing is going to be a pain, I can go back to the version that only passes back "fits with bad blocks", "fits with no bad blocks", or "doesn't fit", and doesn't deal with 64-bit sizes because it's only used by read/write which is limited by pointer size. That simpler version is 128 bytes smaller in my build. -Scott