Re: [PATCH v2 01/14] mtd: rawnand: helper function for setting up ECC parameters

From: Abhishek Sahu
Date: Mon May 07 2018 - 02:02:08 EST


On 2018-05-07 09:10, Masahiro Yamada wrote:
2018-05-03 21:20 GMT+09:00 Abhishek Sahu <absahu@xxxxxxxxxxxxxx>:
commit 2c8f8afa7f92 ("mtd: nand: add generic helpers to check,
match, maximize ECC settings") provides generic helpers which
drivers can use for setting up ECC parameters.

Since same board can have different ECC strength nand chips so
following is the logic for setting up ECC strength and ECC step
size, which can be used by most of the drivers.

1. If both ECC step size and ECC strength are already set
(usually by DT) then just check whether this setting
is supported by NAND controller.
2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength
supported by NAND controller.
3. Otherwise, try to match the ECC step size and ECC strength closest
to the chip's requirement. If available OOB size can't fit the chip
requirement then select maximum ECC strength which can be fit with
available OOB size with warning.

This patch introduces nand_ecc_param_setup function which calls the
required helper functions for the above logic. The drivers can use
this single function instead of calling the 3 helper functions
individually.

CC: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
Signed-off-by: Abhishek Sahu <absahu@xxxxxxxxxxxxxx>
---
* Changes from v1:

NEW PATCH

drivers/mtd/nand/raw/nand_base.c | 42 ++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/rawnand.h | 3 +++
2 files changed, 45 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 72f3a89..dd7a984 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -6249,6 +6249,48 @@ int nand_maximize_ecc(struct nand_chip *chip,
}
EXPORT_SYMBOL_GPL(nand_maximize_ecc);

+/**
+ * nand_ecc_param_setup - Set the ECC strength and ECC step size
+ * @chip: nand chip info structure
+ * @caps: ECC engine caps info structure
+ * @oobavail: OOB size that the ECC engine can use
+ *
+ * Choose the ECC strength according to following logic
+ *
+ * 1. If both ECC step size and ECC strength are already set (usually by DT)
+ * then check if it is supported by this controller.
+ * 2. If NAND_ECC_MAXIMIZE is set, then select maximum ECC strength.
+ * 3. Otherwise, try to match the ECC step size and ECC strength closest
+ * to the chip's requirement. If available OOB size can't fit the chip
+ * requirement then fallback to the maximum ECC step size and ECC strength
+ * and print the warning.
+ *
+ * On success, the chosen ECC settings are set.
+ */
+int nand_ecc_param_setup(struct nand_chip *chip,
+ const struct nand_ecc_caps *caps, int oobavail)
+{
+ int ret;
+
+ if (chip->ecc.size && chip->ecc.strength)
+ return nand_check_ecc_caps(chip, caps, oobavail);
+
+ if (chip->ecc.options & NAND_ECC_MAXIMIZE)
+ return nand_maximize_ecc(chip, caps, oobavail);
+
+ if (!nand_match_ecc_req(chip, caps, oobavail))
+ return 0;
+
+ ret = nand_maximize_ecc(chip, caps, oobavail);


Why two calls for nand_maximize_ecc()?

My code is simpler, and does not display
false-positive warning.


Thanks Masahiro.

Since, Now this is in moved to generic layer that's why I put
this warning that this function is falling back to some
other ECC settings which is not recommend by chip.

If this warning seems unnecessary then I can remove this
and then directly your code changes can be put here
instead of calling nand_maximize_ecc 2 times.


+ if (!ret)
+ pr_warn("ECC (step, strength) = (%d, %d) not supported on this controller. Fallback to (%d, %d)\n",
+ chip->ecc_step_ds, chip->ecc_strength_ds,
+ chip->ecc.size, chip->ecc.strength);


This is annoying.

{ecc_step_ds, ecc_strength_ds} are not provided by Non-ONFi devices.

So,
ECC (step, strength) = (0, 0) not supported on this controller.

will be always displayed.


The strength will be checked by nand_ecc_strength_good() anyway.


But for most of the non ONFI devices also, this is being calculated
by ID.

You can get some background for this in
http://lists.infradead.org/pipermail/linux-mtd/2018-April/080193.html

Regards,
Abhishek