Re: [PATCH 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,

On 25/08/2026 at 11:52, Miquel Raynal wrote:

> It fixes the problem, but honestly modifying the memorg is not
> correct. Broadcom and mpc5121 controller drivers do it, but that's
> likely wrong.
>
> What you report here is a U-Boot issue. The chips has more than 64 OOB
> bytes, U-boot clamps that value, Linux does not. U-boot is wrong. But I
> guess it's now too late and you'll tell me many devices in the field
> already use this broken layout?

Yes, unfortunately. These modules have been shipping since around 2016
with U-Boot and pre-a7ab085d7c16 kernels, both writing the 64-byte
layout, so the bad block tables and every UBI byte on the devices in
the field sit at those offsets. Changing the on-flash layout now would
brick them on the next kernel update.

> In this case, maybe you should just change the layout, instead of
> forcing an obviously incorrect memory layout. In this driver the large
> page generic OOB layout (which puts the ECC bytes at the end) is used. I
> guess a better approach could be to make your own 64-byte clamped OOB
> layout for backward compatibility. You should drop the oobsize
> modification as well.

Agreed, that is cleaner. For v2 I will drop the memorg/oobsize
modification entirely and add driver-specific mtd_ooblayout_ops that
place the ECC bytes inside the first 64 OOB bytes, at the same offsets
as before, regardless of the chip's real OOB size. The controller
setup keeps transferring 64 spare bytes as it always has, so the
on-flash format stays compatible with U-Boot and the old kernels.

> There is at least one legitimate Sashiko warning on this patch, can you
> please also check it?

Yes - the dev_info() uses %d for the u32 oobsize; that message goes
away together with the clamp in v2. While checking the report I also
found two pre-existing issues it flagged: write_page() never copies
chip->oob_poi into the controller SRAM, and vf610_nfc_done() does not
reinit_completion() after a timeout. Both look real and independent of
this fix, so I would send them as separate patches on top.

Thanks,
Mehmet

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