Re: [PATCH v2 1/2] mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB

[Mehmet Fide <mehmet.fide@gmail.com>]

Hi Miquel,

thanks for the review.

> Since it is a total rewrite of the former approach, this is probably a
> good candidate for a Suggested-by.

Of course, I will add your Suggested-by in v3.

> > +/* The controller transfers 64 spare bytes; larger OOBs keep using
> > the first 64 */
>
> Is it a real controller constraint? Or is this a compatibility fix only?
> If this is a real constraint, you can keep the comment, otherwise I
> would drop it.

Compatibility only, so I will drop it. The SRAM row buffer takes up to
248 spare bytes and the ECC engine computes parity for whatever length
is transferred - that is exactly how the bug bites, the parity moves
with the transfer size. The 64 is the on-flash format that U-Boot's
copy of this driver and the kernels before a7ab085d7c16 wrote, and the
explanation belongs at the ooblayout, which brings us to your last
point.

> No explicit inline please.

Dropped.

> Please modify this comment to express why we use our own layout here.

Will do. Something along the lines of: the core's large page layout,
computed over the first 64 spare bytes instead of the whole OOB, so the
ECC bytes stay at the offsets the established on-flash format uses,
while mtd->oobsize keeps reporting the chip's real spare size.

Thanks,
Mehmet

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/