mtd: rawnand: omap: Use BCH private fields in the specific OOB layout
authorMiquel Raynal <miquel.raynal@bootlin.com>
Tue, 19 Jan 2021 15:55:10 +0000 (16:55 +0100)
committerMiquel Raynal <miquel.raynal@bootlin.com>
Wed, 20 Jan 2021 22:38:00 +0000 (23:38 +0100)
commitb135b3358d73aa2a8b2be35d08e422421d1c609e
tree40aabfa6a9cdc3850898c1c940cf643c8e622be5
parente708789c4a87989faff1131ccfdc465a1c1eddbc
mtd: rawnand: omap: Use BCH private fields in the specific OOB layout

The OMAP driver may leverage software BCH logic to locate errors while
using its own hardware to detect the presence of errors. This is
achieved with a "mixed" mode which initializes manually the software
BCH internal logic while providing its own OOB layout.

The issue here comes from the fact that the BCH driver has been
updated to only use generic NAND objects, and no longer depend on raw
NAND structures as it is usable from SPI-NAND as well. However, at the
end of the BCH context initialization, the driver checks the validity
of the OOB layout. At this stage, the raw NAND fields have not been
populated yet while being used by the layout helpers, leading to an
invalid layout.

The chosen solution here is to include the BCH structure definition
and to refer to the BCH fields directly (de-referenced as a const
pointer here) to know as early as possible the number of steps and ECC
bytes which have been chosen.

Note: I don't know which commit exactly triggered the error, but the
entire migration to a generic BCH driver got merged in one go, so this
should not be a problem for stable backports.

Reported-by: Adam Ford <aford173@gmail.com>
Fixes: 80fe603160a4 ("mtd: nand: ecc-bch: Stop using raw NAND structures")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit-28.dts
Link: https://lore.kernel.org/linux-mtd/20210119155510.5655-1-miquel.raynal@bootlin.com
drivers/mtd/nand/raw/omap2.c