diff options
Diffstat (limited to 'target/linux/lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch')
| -rw-r--r-- | target/linux/lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch | 68 |
1 files changed, 68 insertions, 0 deletions
diff --git a/target/linux/lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch b/target/linux/lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch new file mode 100644 index 0000000000..4f23cc94d7 --- /dev/null +++ b/target/linux/lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch @@ -0,0 +1,68 @@ +From ae9a2ac4d283b2925a97523a05ea024499329c16 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal <miquel.raynal@bootlin.com> +Date: Wed, 29 Sep 2021 00:22:58 +0200 +Subject: [PATCH] mtd: rawnand: xway: Keep the driver compatible with on-die + ECC engines + +Following the introduction of the generic ECC engine infrastructure, it +was necessary to reorganize the code and move the ECC configuration in +the ->attach_chip() hook. Failing to do that properly lead to a first +series of fixes supposed to stabilize the situation. Unfortunately, this +only fixed the use of software ECC engines, preventing any other kind of +engine to be used, including on-die ones. + +It is now time to (finally) fix the situation by ensuring that we still +provide a default (eg. software ECC) but will still support different +ECC engines such as on-die ECC engines if properly described in the +device tree. + +There are no changes needed on the core side in order to do this, but we +just need to leverage the logic there which allows: +1- a subsystem default (set to Host engines in the raw NAND world) +2- a driver specific default (here set to software ECC engines) +3- any type of engine requested by the user (ie. described in the DT) + +As the raw NAND subsystem has not yet been fully converted to the ECC +engine infrastructure, in order to provide a default ECC engine for this +driver we need to set chip->ecc.engine_type *before* calling +nand_scan(). During the initialization step, the core will consider this +entry as the default engine for this driver. This value may of course +be overloaded by the user if the usual DT properties are provided. + +Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") +Cc: stable@vger.kernel.org +Cc: Jan Hoffmann <jan@3e8.eu> +Cc: Kestrel seventyfour <kestrelseventyfour@gmail.com> +Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> +--- + drivers/mtd/nand/raw/xway_nand.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/drivers/mtd/nand/raw/xway_nand.c ++++ b/drivers/mtd/nand/raw/xway_nand.c +@@ -148,9 +148,8 @@ static void xway_write_buf(struct nand_c + + static int xway_attach_chip(struct nand_chip *chip) + { +- chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; +- +- if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) ++ if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && ++ chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + return 0; +@@ -219,6 +218,13 @@ static int xway_nand_probe(struct platfo + | NAND_CON_SE_P | NAND_CON_WP_P | NAND_CON_PRE_P + | cs_flag, EBU_NAND_CON); + ++ /* ++ * This driver assumes that the default ECC engine should be TYPE_SOFT. ++ * Set ->engine_type before registering the NAND devices in order to ++ * provide a driver specific default value. ++ */ ++ data->chip.ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; ++ + /* Scan to find existence of the device */ + err = nand_scan(&data->chip, 1); + if (err) |