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

[Miquel Raynal]

On 31/08/2026 at 13:39:59 +02, Mehmet Fide <mehmet.fide@xxxxxxxxx> wrote:

> 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.

I would instead talk about the fact that with 64B OOB chips, the core's
large page layout was matching U-Boot, but U-Boot and older kernel where
clamping the OOB size to 64 if that size was bigger. Modifying the OOB
size is no longer possible (we must respect the actual chip geometry)
but to avoid breaking existing setups, we need our own layout which
only exposes 64 bytes.

Thanks,
Miquèl