On Fri, 2016-02-19 at 18:53 +0100, Marek Vasut wrote: > On 02/13/2016 12:18 AM, Scott Wood wrote: > > On Thu, 2016-01-14 at 02:41 +0100, Marek Vasut wrote: > > > On Tuesday, October 28, 2014 at 11:45:08 PM, Scott Wood wrote: > > > > On Sat, 2014-10-11 at 18:42 +0200, Marek Vasut wrote: > > > > > + /* sometimes people do not think about using the ECC, so > > > > > check > > > > > + * to see if we have an 0xff,0xff,0xff read ECC and then > > > > > ignore > > > > > + * the error, on the assumption that this is an un-eccd > > > > > page. > > > > > + */ > > > > > > > > Eww. I suppose I won't argue too loudly if Linux is doing the same > > > > thing, but what if it's a corrupted blank page, or the ECC just > > > > happened > > > > to turn out as all 0xff? It seems like there should at least be a > > > > warning the first time this happens, and ideally it should be > > > > configurable. > > > > > > > > > + if (read_ecc[0] == 0xff && read_ecc[1] == 0xff && > > > > > read_ecc[2] > > > > > == 0xff > > > > > + /*&& info->platform->ignore_unset_ecc*/) > > > > > > > > > > return 0; > > > > > > > > So it looks like it is configurable in Linux, but you've commented it > > > > out here. > > > > > > > > > @@ -221,6 +298,8 @@ int board_nand_init(struct nand_chip *nand) > > > > > > > > > > nand->dev_ready = s3c24x0_dev_ready; > > > > > > > > > > + nand->chip_delay = 50; > > > > > > > > I'm not sure how this is related to the changes described in the > > > > changelog... > > > > > > Can you collect the MTD patches which are applicable at least and drop > > > this > > > one? > > > > 4/10 is already merged. Which patches are you referring to that don't > > have > > comments, still apply cleanly, and are patching a NAND file? > > Most of this patchset.
Give me one example. I couldn't find any last time I looked. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
