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, 0 insertions, 68 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 deleted file mode 100644 index 4f23cc94d7..0000000000 --- a/target/linux/lantiq/patches-5.10/0016-mtd-rawnand-xway-Keep-the-driver-compatible-with-on-.patch +++ /dev/null @@ -1,68 +0,0 @@ -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) |