[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