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 bengardiner@nanometrics.ca 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