[PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip

Artem Bityutskiy dedekind1 at gmail.com
Thu Aug 25 21:06:28 EST 2011


On Mon, 2011-08-22 at 10:58 -0500, Scott Wood wrote:
> On 08/22/2011 05:58 AM, Artem Bityutskiy wrote:
> > On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
> >> On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> >>> How the bad block marker are handled with this remapping ?
> >>
> >> It has to be migrated prior to first use (this needs to be documented,
> >> and ideally a U-Boot command provided do do this), or else special
> >> handling would be needed when building the BBT.  The only way around
> >> this would be to do ECC in software, and do the buffering needed to let
> >> MTD treat it as a 4K chip.
> > 
> > It really feels like a special hack which would better not go to
> > mainline - am I the only one with such feeling? If yes, probably I am
> > wrong...
> 
> While the implementation is (of necessity) a hack, the feature is
> something that multiple people have been asking for (it's not a special
> case for a specific user).  They say 2K chips are getting more difficult
> to obtain.  It doesn't change anything for people using 512/2K chips,
> and (in its current form) doesn't introduce significant complexity to
> the driver.  I'm not sure how maintaining it out of tree would be a
> better situation for anyone.

I am just afraid that (a) other drivers will do this (b) this will start
causing various weird bug-reports...

-- 
Best Regards,
Artem Bityutskiy



More information about the Linuxppc-dev mailing list