[PATCH v2 2/2] mtd: rawnand: gpmi: Add large oob bch setting support

[Miquel Raynal]

Hi Han,

han.xu at nxp.com wrote on Fri, 25 Mar 2022 16:14:11 -0500:

> The code change proposes a new way to set bch geometry for large oob
> NAND (oobsize > 1KB). In this case, previous implementation can NOT
> guarantee the bad block mark always locates in data chunk, so we need a
> new way to do it, the general idea is,
> 
> 1.Try all ECC strength from the minimum value required by NAND chip to
>   the maximum one that controller can provide, any ECC strength makes
>   the BBM locate in data chunk can be eligible.

Why do you start from the lowest strength towards the biggest? What is
your goal here? Would it be better to do it in the other direction?

> 2.If none of them works, using separate ECC for meta, which will add
>   one extra ecc with the same ECC strength as other data chunks.  This
>   extra ECC can guarantee BBM located in data chunk, also we need to
>   check if oob can afford it.
> 
> Signed-off-by: Han Xu <han.xu at nxp.com>
> 
> ---
> Changes in v2:
>  - split the large oob part to a single patch
> ---
>  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 247 ++++++++++++++++++---
>  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h |  12 +-
>  2 files changed, 228 insertions(+), 31 deletions(-)
> 

[...]

> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h
> index 5e1c3ddae5f8..9ade40d0f586 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.h
> @@ -30,9 +30,9 @@ struct resources {
>   * @page_size:                The size, in bytes, of a physical page, including
>   *                            both data and OOB.
>   * @metadata_size:            The size, in bytes, of the metadata.
> - * @ecc_chunk_size:           The size, in bytes, of a single ECC chunk. Note
> - *                            the first chunk in the page includes both data and
> - *                            metadata, so it's a bit larger than this value.
> + * @ecc_chunk0_size:          The size, in bytes, of a first ECC chunk.
> + * @ecc_chunkn_size:          The size, in bytes, of a single ECC chunk after
> + *                            the first chunk in the page.

I'm not sure what you mean by chunk0 and chunkn all over this patch.
Wouldn't it be "chunk" and "meta_chunk" or something like this?

Perhaps if it is simple you might just do the rename of what is
existing (like chunk -> chunkn if it still applies for instance) and
then in another patch bring support for the meta additional chunk?


Thanks,
Miquèl