Hi Frieder,

Frieder Schrempf [off-list ref] wrote on Mon, 30 Aug
2021 11:18:50 +0200:

On 30.08.21 10:41, Miquel Raynal wrote:

quoted

Hi Frieder,

Frieder Schrempf [off-list ref] wrote on Mon, 30 Aug 2021 09:21:07
+0200:
  

quoted

From: Frieder Schrempf <redacted>

The new generic NAND ECC framework stores the configuration and requirements
in separate places since commit 93ef92f6f422 (" mtd: nand: Use the new generic ECC object ").
In 5.10.x The SPI NAND layer still uses only the requirements to track the ECC
properties. This mismatch leads to values of zero being used for ECC strength
and step_size in the SPI NAND layer wherever nanddev_get_ecc_conf() is used and
therefore breaks the SPI NAND on-die ECC support in 5.10.x.

By using nanddev_get_ecc_requirements() instead of nanddev_get_ecc_conf() for
SPI NAND, we make sure that the correct parameters for the detected chip are
used. In later versions (5.11.x) this is fixed anyway with the implementation
of the SPI NAND on-die ECC engine.

Cc: stable@vger.kernel.org # 5.10.x
Reported-by: voice INTER connect GmbH <redacted>
Signed-off-by: Frieder Schrempf <redacted>  

Why not just reverting 9a333a72c1d0 ("mtd: spinand: Use
nanddev_get_ecc_conf() when relevant")? I think using this "new"
nanddev_get_ecc_requirements() helper because it fits the purpose even
if it is wrong [1] doesn't bring the right information. I know it is
strictly equivalent but I would personally prefer keeping the old
writing "nand->eccreq.xxxx".  

I think reverting 9a333a72c1d0 to use nand->eccreq.xxxx doesn't work as the eccreq member has already been removed in 93ef92f6f422 ("mtd: nand: Use the new generic ECC object"). So we would need to revert this commit, too. That would work for the SPI NAND layer, but might have implications on RAW NAND as it already uses the new generic ECC object with 'ctx.conf' and 'requirements'. At least I can't tell how this would affect the RAW NAND layer.

I missed that, you're right.

Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>

quoted

[1] We don't want the requirements but the actual current configuration
here, which was the primary purpose of the initial patch which ended
being a mistake at that point in time because the SPI-NAND core was not
ready yet.

Thanks,
Miquèl  

Thanks,
Miquèl