--- /dev/null
+From c302c98da646409d657a473da202f10f417f3ff1 Mon Sep 17 00:00:00 2001
+From: Jernej Skrabec <jernej.skrabec@gmail.com>
+Date: Tue, 31 Aug 2021 20:48:19 +0200
+Subject: drm/sun4i: Fix macros in sun8i_csc.h
+
+From: Jernej Skrabec <jernej.skrabec@gmail.com>
+
+commit c302c98da646409d657a473da202f10f417f3ff1 upstream.
+
+Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
+recommendation of having arguments enclosed in parenthesis. While that
+didn't change anything for quite sometime, it actually become important
+after CSC code rework with commit ea067aee45a8 ("drm/sun4i: de2/de3:
+Remove redundant CSC matrices").
+
+Without this fix, colours are completely off for supported YVU formats
+on SoCs with DE2 (A64, H3, R40, etc.).
+
+Fix the issue by enclosing macro arguments in parenthesis.
+
+Cc: stable@vger.kernel.org # 5.12+
+Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
+Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
+Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
+Reviewed-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20210831184819.93670-1-jernej.skrabec@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/sun4i/sun8i_csc.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/sun4i/sun8i_csc.h
++++ b/drivers/gpu/drm/sun4i/sun8i_csc.h
+@@ -16,8 +16,8 @@ struct sun8i_mixer;
+ #define CCSC10_OFFSET 0xA0000
+ #define CCSC11_OFFSET 0xF0000
+
+-#define SUN8I_CSC_CTRL(base) (base + 0x0)
+-#define SUN8I_CSC_COEFF(base, i) (base + 0x10 + 4 * i)
++#define SUN8I_CSC_CTRL(base) ((base) + 0x0)
++#define SUN8I_CSC_COEFF(base, i) ((base) + 0x10 + 4 * (i))
+
+ #define SUN8I_CSC_CTRL_EN BIT(0)
+
--- /dev/null
+From d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:40 +0200
+Subject: mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d upstream.
+
+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: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/ams-delta.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/ams-delta.c
++++ b/drivers/mtd/nand/raw/ams-delta.c
+@@ -217,9 +217,8 @@ static int gpio_nand_setup_interface(str
+
+ static int gpio_nand_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;
+@@ -370,6 +369,13 @@ static int gpio_nand_probe(struct platfo
+ /* Release write protection */
+ gpiod_set_value(priv->gpiod_nwp, 0);
+
++ /*
++ * 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.
++ */
++ this->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
++
+ /* Scan to find existence of the device */
+ err = nand_scan(this, 1);
+ if (err)
--- /dev/null
+From 7e3cdba176ba59eaf4d463d273da0718e3626140 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:41 +0200
+Subject: mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 7e3cdba176ba59eaf4d463d273da0718e3626140 upstream.
+
+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: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/au1550nd.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/au1550nd.c
++++ b/drivers/mtd/nand/raw/au1550nd.c
+@@ -239,9 +239,8 @@ static int au1550nd_exec_op(struct nand_
+
+ static int au1550nd_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;
+@@ -310,6 +309,13 @@ static int au1550nd_probe(struct platfor
+ if (pd->devwidth)
+ this->options |= NAND_BUSWIDTH_16;
+
++ /*
++ * 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.
++ */
++ this->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
++
+ ret = nand_scan(this, 1);
+ if (ret) {
+ dev_err(&pdev->dev, "NAND scan failed with %d\n", ret);
--- /dev/null
+From 9be1446ece291a1f08164bd056bed3d698681f8b Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:15:00 +0200
+Subject: mtd: rawnand: fsmc: Fix use of SM ORDER
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 9be1446ece291a1f08164bd056bed3d698681f8b upstream.
+
+The introduction of the generic ECC engine API lead to a number of
+changes in various drivers which broke some of them. Here is a typical
+example: I expected the SM_ORDER option to be handled by the Hamming ECC
+engine internals. Problem: the fsmc driver does not instantiate (yet) a
+real ECC engine object so we had to use a 'bare' ECC helper instead of
+the shiny rawnand functions. However, when not intializing this engine
+properly and using the bare helpers, we do not get the SM ORDER feature
+handled automatically. It looks like this was lost in the process so
+let's ensure we use the right SM ORDER now.
+
+Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/fsmc_nand.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/raw/fsmc_nand.c
++++ b/drivers/mtd/nand/raw/fsmc_nand.c
+@@ -438,8 +438,10 @@ static int fsmc_correct_ecc1(struct nand
+ unsigned char *read_ecc,
+ unsigned char *calc_ecc)
+ {
++ bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER;
++
+ return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc,
+- chip->ecc.size, false);
++ chip->ecc.size, sm_order);
+ }
+
+ /* Count the number of 0's in buff upto a max of max_bits */
--- /dev/null
+From b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:42 +0200
+Subject: mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 upstream.
+
+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: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/gpio.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/gpio.c
++++ b/drivers/mtd/nand/raw/gpio.c
+@@ -163,9 +163,8 @@ static int gpio_nand_exec_op(struct nand
+
+ static int gpio_nand_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;
+@@ -365,6 +364,13 @@ static int gpio_nand_probe(struct platfo
+ if (gpiomtd->nwp && !IS_ERR(gpiomtd->nwp))
+ gpiod_direction_output(gpiomtd->nwp, 1);
+
++ /*
++ * 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.
++ */
++ chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
++
+ ret = nand_scan(chip, 1);
+ if (ret)
+ goto err_wp;
--- /dev/null
+From f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:43 +0200
+Subject: mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 upstream.
+
+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: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/mpc5121_nfc.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/mpc5121_nfc.c
++++ b/drivers/mtd/nand/raw/mpc5121_nfc.c
+@@ -605,9 +605,8 @@ static void mpc5121_nfc_free(struct devi
+
+ static int mpc5121_nfc_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;
+@@ -772,6 +771,13 @@ static int mpc5121_nfc_probe(struct plat
+ goto error;
+ }
+
++ /*
++ * 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.
++ */
++ chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
++
+ /* Detect NAND chips */
+ retval = nand_scan(chip, be32_to_cpup(chips_no));
+ if (retval) {
--- /dev/null
+From 194ac63de6ff56d30c48e3ac19c8a412f9c1408e Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:44 +0200
+Subject: mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 194ac63de6ff56d30c48e3ac19c8a412f9c1408e upstream.
+
+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: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/orion_nand.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/orion_nand.c
++++ b/drivers/mtd/nand/raw/orion_nand.c
+@@ -85,9 +85,8 @@ static void orion_nand_read_buf(struct n
+
+ static int orion_nand_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;
+@@ -190,6 +189,13 @@ static int __init orion_nand_probe(struc
+ return ret;
+ }
+
++ /*
++ * 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.
++ */
++ nc->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
++
+ ret = nand_scan(nc, 1);
+ if (ret)
+ goto no_dev;
--- /dev/null
+From f16b7d2a5e810fcf4b15d096246d0d445da9cc88 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:45 +0200
+Subject: mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit f16b7d2a5e810fcf4b15d096246d0d445da9cc88 upstream.
+
+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: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/pasemi_nand.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/pasemi_nand.c
++++ b/drivers/mtd/nand/raw/pasemi_nand.c
+@@ -75,9 +75,8 @@ static int pasemi_device_ready(struct na
+
+ static int pasemi_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;
+@@ -154,6 +153,13 @@ static int pasemi_nand_probe(struct plat
+ /* Enable the following for a flash based bad block table */
+ chip->bbt_options = NAND_BBT_USE_FLASH;
+
++ /*
++ * 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.
++ */
++ chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT;
++
+ /* Scan to find existence of the device */
+ err = nand_scan(chip, 1);
+ if (err)
--- /dev/null
+From 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:46 +0200
+Subject: mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 upstream.
+
+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: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/plat_nand.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/plat_nand.c
++++ b/drivers/mtd/nand/raw/plat_nand.c
+@@ -21,9 +21,8 @@ struct plat_nand_data {
+
+ static int plat_nand_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;
+@@ -94,6 +93,13 @@ static int plat_nand_probe(struct platfo
+ goto out;
+ }
+
++ /*
++ * 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, pdata->chip.nr_chips);
+ if (err)
--- /dev/null
+From 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Wed, 29 Sep 2021 00:22:48 +0200
+Subject: mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 upstream.
+
+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>
+Tested-by: Jan Hoffmann <jan@3e8.eu>
+Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 81291383ffde08b23bce75e7d6b2575ce9d3475c Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Thu, 28 Oct 2021 23:30:43 +1000
+Subject: powerpc/32e: Ignore ESR in instruction storage interrupt handler
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit 81291383ffde08b23bce75e7d6b2575ce9d3475c upstream.
+
+A e5500 machine running a 32-bit kernel sometimes hangs at boot,
+seemingly going into an infinite loop of instruction storage interrupts.
+
+The ESR (Exception Syndrome Register) has a value of 0x800000 (store)
+when this happens, which is likely set by a previous store. An
+instruction TLB miss interrupt would then leave ESR unchanged, and if no
+PTE exists it calls directly to the instruction storage interrupt
+handler without changing ESR.
+
+access_error() does not cause a segfault due to a store to a read-only
+vma because is_exec is true. Most subsequent fault handling does not
+check for a write fault on a read-only vma, and might do strange things
+like create a writeable PTE or call page_mkwrite on a read only vma or
+file. It's not clear what happens here to cause the infinite faulting in
+this case, a fault handler failure or low level PTE or TLB handling.
+
+In any case this can be fixed by having the instruction storage
+interrupt zero regs->dsisr rather than storing the ESR value to it.
+
+Fixes: a01a3f2ddbcd ("powerpc: remove arguments from fault handler functions")
+Cc: stable@vger.kernel.org # v5.12+
+Reported-by: Jacques de Laval <jacques.delaval@protonmail.com>
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Tested-by: Jacques de Laval <jacques.delaval@protonmail.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211028133043.4159501-1-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/head_booke.h | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+--- a/arch/powerpc/kernel/head_booke.h
++++ b/arch/powerpc/kernel/head_booke.h
+@@ -465,12 +465,21 @@ label:
+ bl do_page_fault; \
+ b interrupt_return
+
++/*
++ * Instruction TLB Error interrupt handlers may call InstructionStorage
++ * directly without clearing ESR, so the ESR at this point may be left over
++ * from a prior interrupt.
++ *
++ * In any case, do_page_fault for BOOK3E does not use ESR and always expects
++ * dsisr to be 0. ESR_DST from a prior store in particular would confuse fault
++ * handling.
++ */
+ #define INSTRUCTION_STORAGE_EXCEPTION \
+ START_EXCEPTION(InstructionStorage) \
+- NORMAL_EXCEPTION_PROLOG(0x400, INST_STORAGE); \
+- mfspr r5,SPRN_ESR; /* Grab the ESR and save it */ \
++ NORMAL_EXCEPTION_PROLOG(0x400, INST_STORAGE); \
++ li r5,0; /* Store 0 in regs->esr (dsisr) */ \
+ stw r5,_ESR(r11); \
+- stw r12, _DEAR(r11); /* Pass SRR0 as arg2 */ \
++ stw r12, _DEAR(r11); /* Set regs->dear (dar) to SRR0 */ \
+ prepare_transfer_to_handler; \
+ bl do_page_fault; \
+ b interrupt_return
--- /dev/null
+From 4a5cb51f3db4be547225a4bce7a43d41b231382b Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Tue, 26 Oct 2021 22:25:31 +1000
+Subject: powerpc/64s/interrupt: Fix check_return_regs_valid() false positive
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit 4a5cb51f3db4be547225a4bce7a43d41b231382b upstream.
+
+The check_return_regs_valid() can cause a false positive if the return
+regs are marked as norestart and they are an HSRR type interrupt,
+because the low bit in the bottom of regs->trap causes interrupt type
+matching to fail.
+
+This can occcur for example on bare metal with a HV privileged doorbell
+interrupt that causes a signal, but do_signal returns early because
+get_signal() fails, and takes the "No signal to deliver" path. In this
+case no signal was delivered so the return location is not changed so
+return SRRs are not invalidated, yet set_trap_norestart is called, which
+messes up the match. Building go-1.16.6 is known to reproduce this.
+
+Fix it by using the TRAP() accessor which masks out the low bit.
+
+Fixes: 6eaaf9de3599 ("powerpc/64s/interrupt: Check and fix srr_valid without crashing")
+Cc: stable@vger.kernel.org # v5.14+
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211026122531.3599918-1-npiggin@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/interrupt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/kernel/interrupt.c
++++ b/arch/powerpc/kernel/interrupt.c
+@@ -266,7 +266,7 @@ static void check_return_regs_valid(stru
+ if (trap_is_scv(regs))
+ return;
+
+- trap = regs->trap;
++ trap = TRAP(regs);
+ // EE in HV mode sets HSRRs like 0xea0
+ if (cpu_has_feature(CPU_FTR_HVMODE) && trap == INTERRUPT_EXTERNAL)
+ trap = 0xea0;
--- /dev/null
+From c45361abb9185b1e172bd75eff51ad5f601ccae4 Mon Sep 17 00:00:00 2001
+From: Xiaoming Ni <nixiaoming@huawei.com>
+Date: Wed, 29 Sep 2021 11:36:46 +0800
+Subject: powerpc/85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n
+
+From: Xiaoming Ni <nixiaoming@huawei.com>
+
+commit c45361abb9185b1e172bd75eff51ad5f601ccae4 upstream.
+
+When CONFIG_SMP=y, timebase synchronization is required when the second
+kernel is started.
+
+arch/powerpc/kernel/smp.c:
+ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
+ {
+ ...
+ if (smp_ops->give_timebase)
+ smp_ops->give_timebase();
+ ...
+ }
+
+ void start_secondary(void *unused)
+ {
+ ...
+ if (smp_ops->take_timebase)
+ smp_ops->take_timebase();
+ ...
+ }
+
+When CONFIG_HOTPLUG_CPU=n and CONFIG_KEXEC_CORE=n,
+ smp_85xx_ops.give_timebase is NULL,
+ smp_85xx_ops.take_timebase is NULL,
+As a result, the timebase is not synchronized.
+
+Timebase synchronization does not depend on CONFIG_HOTPLUG_CPU.
+
+Fixes: 56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations")
+Cc: stable@vger.kernel.org # v4.6+
+Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210929033646.39630-3-nixiaoming@huawei.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/85xx/Makefile | 4 +++-
+ arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c | 4 ++++
+ arch/powerpc/platforms/85xx/smp.c | 12 ++++++------
+ 3 files changed, 13 insertions(+), 7 deletions(-)
+
+--- a/arch/powerpc/platforms/85xx/Makefile
++++ b/arch/powerpc/platforms/85xx/Makefile
+@@ -3,7 +3,9 @@
+ # Makefile for the PowerPC 85xx linux kernel.
+ #
+ obj-$(CONFIG_SMP) += smp.o
+-obj-$(CONFIG_FSL_PMC) += mpc85xx_pm_ops.o
++ifneq ($(CONFIG_FSL_CORENET_RCPM),y)
++obj-$(CONFIG_SMP) += mpc85xx_pm_ops.o
++endif
+
+ obj-y += common.o
+
+--- a/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
++++ b/arch/powerpc/platforms/85xx/mpc85xx_pm_ops.c
+@@ -17,6 +17,7 @@
+
+ static struct ccsr_guts __iomem *guts;
+
++#ifdef CONFIG_FSL_PMC
+ static void mpc85xx_irq_mask(int cpu)
+ {
+
+@@ -49,6 +50,7 @@ static void mpc85xx_cpu_up_prepare(int c
+ {
+
+ }
++#endif
+
+ static void mpc85xx_freeze_time_base(bool freeze)
+ {
+@@ -76,10 +78,12 @@ static const struct of_device_id mpc85xx
+
+ static const struct fsl_pm_ops mpc85xx_pm_ops = {
+ .freeze_time_base = mpc85xx_freeze_time_base,
++#ifdef CONFIG_FSL_PMC
+ .irq_mask = mpc85xx_irq_mask,
+ .irq_unmask = mpc85xx_irq_unmask,
+ .cpu_die = mpc85xx_cpu_die,
+ .cpu_up_prepare = mpc85xx_cpu_up_prepare,
++#endif
+ };
+
+ int __init mpc85xx_setup_pmc(void)
+--- a/arch/powerpc/platforms/85xx/smp.c
++++ b/arch/powerpc/platforms/85xx/smp.c
+@@ -40,7 +40,6 @@ struct epapr_spin_table {
+ u32 pir;
+ };
+
+-#ifdef CONFIG_HOTPLUG_CPU
+ static u64 timebase;
+ static int tb_req;
+ static int tb_valid;
+@@ -112,6 +111,7 @@ static void mpc85xx_take_timebase(void)
+ local_irq_restore(flags);
+ }
+
++#ifdef CONFIG_HOTPLUG_CPU
+ static void smp_85xx_cpu_offline_self(void)
+ {
+ unsigned int cpu = smp_processor_id();
+@@ -495,21 +495,21 @@ void __init mpc85xx_smp_init(void)
+ smp_85xx_ops.probe = NULL;
+ }
+
+-#ifdef CONFIG_HOTPLUG_CPU
+ #ifdef CONFIG_FSL_CORENET_RCPM
++ /* Assign a value to qoriq_pm_ops on PPC_E500MC */
+ fsl_rcpm_init();
+-#endif
+-
+-#ifdef CONFIG_FSL_PMC
++#else
++ /* Assign a value to qoriq_pm_ops on !PPC_E500MC */
+ mpc85xx_setup_pmc();
+ #endif
+ if (qoriq_pm_ops) {
+ smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
+ smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
++#ifdef CONFIG_HOTPLUG_CPU
+ smp_85xx_ops.cpu_offline_self = smp_85xx_cpu_offline_self;
+ smp_85xx_ops.cpu_die = qoriq_cpu_kill;
+- }
+ #endif
++ }
+ smp_ops = &smp_85xx_ops;
+
+ #ifdef CONFIG_KEXEC_CORE
--- /dev/null
+From 44a8214de96bafb5210e43bfa2c97c19bf75af3d Mon Sep 17 00:00:00 2001
+From: Hari Bathini <hbathini@linux.ibm.com>
+Date: Mon, 25 Oct 2021 11:26:49 +0530
+Subject: powerpc/bpf: Fix write protecting JIT code
+
+From: Hari Bathini <hbathini@linux.ibm.com>
+
+commit 44a8214de96bafb5210e43bfa2c97c19bf75af3d upstream.
+
+Running program with bpf-to-bpf function calls results in data access
+exception (0x300) with the below call trace:
+
+ bpf_int_jit_compile+0x238/0x750 (unreliable)
+ bpf_check+0x2008/0x2710
+ bpf_prog_load+0xb00/0x13a0
+ __sys_bpf+0x6f4/0x27c0
+ sys_bpf+0x2c/0x40
+ system_call_exception+0x164/0x330
+ system_call_vectored_common+0xe8/0x278
+
+as bpf_int_jit_compile() tries writing to write protected JIT code
+location during the extra pass.
+
+Fix it by holding off write protection of JIT code until the extra
+pass, where branch target addresses fixup happens.
+
+Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code")
+Cc: stable@vger.kernel.org # v5.14+
+Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
+Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211025055649.114728-1-hbathini@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/net/bpf_jit_comp.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/net/bpf_jit_comp.c
++++ b/arch/powerpc/net/bpf_jit_comp.c
+@@ -241,8 +241,8 @@ skip_codegen_passes:
+ fp->jited_len = alloclen;
+
+ bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE));
+- bpf_jit_binary_lock_ro(bpf_hdr);
+ if (!fp->is_func || extra_pass) {
++ bpf_jit_binary_lock_ro(bpf_hdr);
+ bpf_prog_fill_jited_linfo(fp, addrs);
+ out_addrs:
+ kfree(addrs);
--- /dev/null
+From 52862ab33c5d97490f3fa345d6529829e6d6637b Mon Sep 17 00:00:00 2001
+From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
+Date: Thu, 28 Oct 2021 22:27:16 +0530
+Subject: powerpc/powernv/prd: Unregister OPAL_MSG_PRD2 notifier during module unload
+
+From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
+
+commit 52862ab33c5d97490f3fa345d6529829e6d6637b upstream.
+
+Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and
+added opal notifier. But I missed to unregister the notifier during
+module unload path. This results in below call trace if you try to
+unload and load opal_prd module.
+
+Also add new notifier_block for OPAL_MSG_PRD2 message.
+
+Sample calltrace (modprobe -r opal_prd; modprobe opal_prd)
+ BUG: Unable to handle kernel data access on read at 0xc0080000192200e0
+ Faulting instruction address: 0xc00000000018d1cc
+ Oops: Kernel access of bad area, sig: 11 [#1]
+ LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
+ CPU: 66 PID: 7446 Comm: modprobe Kdump: loaded Tainted: G E 5.14.0prd #759
+ NIP: c00000000018d1cc LR: c00000000018d2a8 CTR: c0000000000cde10
+ REGS: c0000003c4c0f0a0 TRAP: 0300 Tainted: G E (5.14.0prd)
+ MSR: 9000000002009033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 24224824 XER: 20040000
+ CFAR: c00000000018d2a4 DAR: c0080000192200e0 DSISR: 40000000 IRQMASK: 1
+ ...
+ NIP notifier_chain_register+0x2c/0xc0
+ LR atomic_notifier_chain_register+0x48/0x80
+ Call Trace:
+ 0xc000000002090610 (unreliable)
+ atomic_notifier_chain_register+0x58/0x80
+ opal_message_notifier_register+0x7c/0x1e0
+ opal_prd_probe+0x84/0x150 [opal_prd]
+ platform_probe+0x78/0x130
+ really_probe+0x110/0x5d0
+ __driver_probe_device+0x17c/0x230
+ driver_probe_device+0x60/0x130
+ __driver_attach+0xfc/0x220
+ bus_for_each_dev+0xa8/0x130
+ driver_attach+0x34/0x50
+ bus_add_driver+0x1b0/0x300
+ driver_register+0x98/0x1a0
+ __platform_driver_register+0x38/0x50
+ opal_prd_driver_init+0x34/0x50 [opal_prd]
+ do_one_initcall+0x60/0x2d0
+ do_init_module+0x7c/0x320
+ load_module+0x3394/0x3650
+ __do_sys_finit_module+0xd4/0x160
+ system_call_exception+0x140/0x290
+ system_call_common+0xf4/0x258
+
+Fixes: 587164cd593c ("powerpc/powernv: Add new opal message type")
+Cc: stable@vger.kernel.org # v5.4+
+Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211028165716.41300-1-hegdevasant@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/powernv/opal-prd.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/powernv/opal-prd.c
++++ b/arch/powerpc/platforms/powernv/opal-prd.c
+@@ -369,6 +369,12 @@ static struct notifier_block opal_prd_ev
+ .priority = 0,
+ };
+
++static struct notifier_block opal_prd_event_nb2 = {
++ .notifier_call = opal_prd_msg_notifier,
++ .next = NULL,
++ .priority = 0,
++};
++
+ static int opal_prd_probe(struct platform_device *pdev)
+ {
+ int rc;
+@@ -390,9 +396,10 @@ static int opal_prd_probe(struct platfor
+ return rc;
+ }
+
+- rc = opal_message_notifier_register(OPAL_MSG_PRD2, &opal_prd_event_nb);
++ rc = opal_message_notifier_register(OPAL_MSG_PRD2, &opal_prd_event_nb2);
+ if (rc) {
+ pr_err("Couldn't register PRD2 event notifier\n");
++ opal_message_notifier_unregister(OPAL_MSG_PRD, &opal_prd_event_nb);
+ return rc;
+ }
+
+@@ -401,6 +408,8 @@ static int opal_prd_probe(struct platfor
+ pr_err("failed to register miscdev\n");
+ opal_message_notifier_unregister(OPAL_MSG_PRD,
+ &opal_prd_event_nb);
++ opal_message_notifier_unregister(OPAL_MSG_PRD2,
++ &opal_prd_event_nb2);
+ return rc;
+ }
+
+@@ -411,6 +420,7 @@ static int opal_prd_remove(struct platfo
+ {
+ misc_deregister(&opal_prd_dev);
+ opal_message_notifier_unregister(OPAL_MSG_PRD, &opal_prd_event_nb);
++ opal_message_notifier_unregister(OPAL_MSG_PRD2, &opal_prd_event_nb2);
+ return 0;
+ }
+
--- /dev/null
+From 319fa1a52e438a6e028329187783a25ad498c4e6 Mon Sep 17 00:00:00 2001
+From: Nathan Lynch <nathanl@linux.ibm.com>
+Date: Wed, 20 Oct 2021 14:47:03 -0500
+Subject: powerpc/pseries/mobility: ignore ibm, platform-facilities updates
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Nathan Lynch <nathanl@linux.ibm.com>
+
+commit 319fa1a52e438a6e028329187783a25ad498c4e6 upstream.
+
+On VMs with NX encryption, compression, and/or RNG offload, these
+capabilities are described by nodes in the ibm,platform-facilities device
+tree hierarchy:
+
+ $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
+ /sys/firmware/devicetree/base/ibm,platform-facilities/
+ ├── ibm,compression-v1
+ ├── ibm,random-v1
+ └── ibm,sym-encryption-v1
+
+ 3 directories
+
+The acceleration functions that these nodes describe are not disrupted by
+live migration, not even temporarily.
+
+But the post-migration ibm,update-nodes sequence firmware always sends
+"delete" messages for this hierarchy, followed by an "add" directive to
+reconstruct it via ibm,configure-connector (log with debugging statements
+enabled in mobility.c):
+
+ mobility: removing node /ibm,platform-facilities/ibm,random-v1:4294967285
+ mobility: removing node /ibm,platform-facilities/ibm,compression-v1:4294967284
+ mobility: removing node /ibm,platform-facilities/ibm,sym-encryption-v1:4294967283
+ mobility: removing node /ibm,platform-facilities:4294967286
+ ...
+ mobility: added node /ibm,platform-facilities:4294967286
+
+Note we receive a single "add" message for the entire hierarchy, and what
+we receive from the ibm,configure-connector sequence is the top-level
+platform-facilities node along with its three children. The debug message
+simply reports the parent node and not the whole subtree.
+
+Also, significantly, the nodes added are almost completely equivalent to
+the ones removed; even phandles are unchanged. ibm,shared-interrupt-pool in
+the leaf nodes is the only property I've observed to differ, and Linux does
+not use that. So in practice, the sum of update messages Linux receives for
+this hierarchy is equivalent to minor property updates.
+
+We succeed in removing the original hierarchy from the device tree. But the
+vio bus code is ignorant of this, and does not unbind or relinquish its
+references. The leaf nodes, still reachable through sysfs, of course still
+refer to the now-freed ibm,platform-facilities parent node, which makes
+use-after-free possible:
+
+ refcount_t: addition on 0; use-after-free.
+ WARNING: CPU: 3 PID: 1706 at lib/refcount.c:25 refcount_warn_saturate+0x164/0x1f0
+ refcount_warn_saturate+0x160/0x1f0 (unreliable)
+ kobject_get+0xf0/0x100
+ of_node_get+0x30/0x50
+ of_get_parent+0x50/0xb0
+ of_fwnode_get_parent+0x54/0x90
+ fwnode_count_parents+0x50/0x150
+ fwnode_full_name_string+0x30/0x110
+ device_node_string+0x49c/0x790
+ vsnprintf+0x1c0/0x4c0
+ sprintf+0x44/0x60
+ devspec_show+0x34/0x50
+ dev_attr_show+0x40/0xa0
+ sysfs_kf_seq_show+0xbc/0x200
+ kernfs_seq_show+0x44/0x60
+ seq_read_iter+0x2a4/0x740
+ kernfs_fop_read_iter+0x254/0x2e0
+ new_sync_read+0x120/0x190
+ vfs_read+0x1d0/0x240
+
+Moreover, the "new" replacement subtree is not correctly added to the
+device tree, resulting in ibm,platform-facilities parent node without the
+appropriate leaf nodes, and broken symlinks in the sysfs device hierarchy:
+
+ $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
+ /sys/firmware/devicetree/base/ibm,platform-facilities/
+
+ 0 directories
+
+ $ cd /sys/devices/vio ; find . -xtype l -exec file {} +
+ ./ibm,sym-encryption-v1/of_node: broken symbolic link to
+ ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,sym-encryption-v1
+ ./ibm,random-v1/of_node: broken symbolic link to
+ ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,random-v1
+ ./ibm,compression-v1/of_node: broken symbolic link to
+ ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,compression-v1
+
+This is because add_dt_node() -> dlpar_attach_node() attaches only the
+parent node returned from configure-connector, ignoring any children. This
+should be corrected for the general case, but fixing that won't help with
+the stale OF node references, which is the more urgent problem.
+
+One way to address that would be to make the drivers respond to node
+removal notifications, so that node references can be dropped
+appropriately. But this would likely force the drivers to disrupt active
+clients for no useful purpose: equivalent nodes are immediately re-added.
+And recall that the acceleration capabilities described by the nodes remain
+available throughout the whole process.
+
+The solution I believe to be robust for this situation is to convert
+remove+add of a node with an unchanged phandle to an update of the node's
+properties in the Linux device tree structure. That would involve changing
+and adding a fair amount of code, and may take several iterations to land.
+
+Until that can be realized we have a confirmed use-after-free and the
+possibility of memory corruption. So add a limited workaround that
+discriminates on the node type, ignoring adds and removes. This should be
+amenable to backporting in the meantime.
+
+Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
+Cc: stable@vger.kernel.org
+Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211020194703.2613093-1-nathanl@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/pseries/mobility.c | 34 ++++++++++++++++++++++++++++++
+ 1 file changed, 34 insertions(+)
+
+--- a/arch/powerpc/platforms/pseries/mobility.c
++++ b/arch/powerpc/platforms/pseries/mobility.c
+@@ -63,6 +63,27 @@ static int mobility_rtas_call(int token,
+
+ static int delete_dt_node(struct device_node *dn)
+ {
++ struct device_node *pdn;
++ bool is_platfac;
++
++ pdn = of_get_parent(dn);
++ is_platfac = of_node_is_type(dn, "ibm,platform-facilities") ||
++ of_node_is_type(pdn, "ibm,platform-facilities");
++ of_node_put(pdn);
++
++ /*
++ * The drivers that bind to nodes in the platform-facilities
++ * hierarchy don't support node removal, and the removal directive
++ * from firmware is always followed by an add of an equivalent
++ * node. The capability (e.g. RNG, encryption, compression)
++ * represented by the node is never interrupted by the migration.
++ * So ignore changes to this part of the tree.
++ */
++ if (is_platfac) {
++ pr_notice("ignoring remove operation for %pOFfp\n", dn);
++ return 0;
++ }
++
+ pr_debug("removing node %pOFfp\n", dn);
+ dlpar_detach_node(dn);
+ return 0;
+@@ -222,6 +243,19 @@ static int add_dt_node(struct device_nod
+ if (!dn)
+ return -ENOENT;
+
++ /*
++ * Since delete_dt_node() ignores this node type, this is the
++ * necessary counterpart. We also know that a platform-facilities
++ * node returned from dlpar_configure_connector() has children
++ * attached, and dlpar_attach_node() only adds the parent, leaking
++ * the children. So ignore these on the add side for now.
++ */
++ if (of_node_is_type(dn, "ibm,platform-facilities")) {
++ pr_notice("ignoring add operation for %pOF\n", dn);
++ dlpar_free_cc_nodes(dn);
++ return 0;
++ }
++
+ rc = dlpar_attach_node(dn, parent_dn);
+ if (rc)
+ dlpar_free_cc_nodes(dn);
--- /dev/null
+From 3c12b4df8d5e026345a19886ae375b3ebc33c0b6 Mon Sep 17 00:00:00 2001
+From: Russell Currey <ruscur@russell.cc>
+Date: Wed, 27 Oct 2021 17:24:10 +1000
+Subject: powerpc/security: Use a mutex for interrupt exit code patching
+
+From: Russell Currey <ruscur@russell.cc>
+
+commit 3c12b4df8d5e026345a19886ae375b3ebc33c0b6 upstream.
+
+The mitigation-patching.sh script in the powerpc selftests toggles
+all mitigations on and off simultaneously, revealing that rfi_flush
+and stf_barrier cannot safely operate at the same time due to races
+in updating the static key.
+
+On some systems, the static key code throws a warning and the kernel
+remains functional. On others, the kernel will hang or crash.
+
+Fix this by slapping on a mutex.
+
+Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt")
+Cc: stable@vger.kernel.org # v5.14+
+Signed-off-by: Russell Currey <ruscur@russell.cc>
+Acked-by: Nicholas Piggin <npiggin@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211027072410.40950-1-ruscur@russell.cc
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/lib/feature-fixups.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/arch/powerpc/lib/feature-fixups.c
++++ b/arch/powerpc/lib/feature-fixups.c
+@@ -228,6 +228,7 @@ static void do_stf_exit_barrier_fixups(e
+
+ static bool stf_exit_reentrant = false;
+ static bool rfi_exit_reentrant = false;
++static DEFINE_MUTEX(exit_flush_lock);
+
+ static int __do_stf_barrier_fixups(void *data)
+ {
+@@ -253,6 +254,9 @@ void do_stf_barrier_fixups(enum stf_barr
+ * low level interrupt exit code before patching. After the patching,
+ * if allowed, then flip the branch to allow fast exits.
+ */
++
++ // Prevent static key update races with do_rfi_flush_fixups()
++ mutex_lock(&exit_flush_lock);
+ static_branch_enable(&interrupt_exit_not_reentrant);
+
+ stop_machine(__do_stf_barrier_fixups, &types, NULL);
+@@ -264,6 +268,8 @@ void do_stf_barrier_fixups(enum stf_barr
+
+ if (stf_exit_reentrant && rfi_exit_reentrant)
+ static_branch_disable(&interrupt_exit_not_reentrant);
++
++ mutex_unlock(&exit_flush_lock);
+ }
+
+ void do_uaccess_flush_fixups(enum l1d_flush_type types)
+@@ -486,6 +492,9 @@ void do_rfi_flush_fixups(enum l1d_flush_
+ * without stop_machine, so this could be achieved with a broadcast
+ * IPI instead, but this matches the stf sequence.
+ */
++
++ // Prevent static key update races with do_stf_barrier_fixups()
++ mutex_lock(&exit_flush_lock);
+ static_branch_enable(&interrupt_exit_not_reentrant);
+
+ stop_machine(__do_rfi_flush_fixups, &types, NULL);
+@@ -497,6 +506,8 @@ void do_rfi_flush_fixups(enum l1d_flush_
+
+ if (stf_exit_reentrant && rfi_exit_reentrant)
+ static_branch_disable(&interrupt_exit_not_reentrant);
++
++ mutex_unlock(&exit_flush_lock);
+ }
+
+ void do_barrier_nospec_fixups_range(bool enable, void *fixup_start, void *fixup_end)
--- /dev/null
+From 61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
+Date: Fri, 15 Oct 2021 00:03:45 -0500
+Subject: powerpc/vas: Fix potential NULL pointer dereference
+
+From: Gustavo A. R. Silva <gustavoars@kernel.org>
+
+commit 61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36 upstream.
+
+(!ptr && !ptr->foo) strikes again. :)
+
+The expression (!ptr && !ptr->foo) is bogus and in case ptr is NULL,
+it leads to a NULL pointer dereference: ptr->foo.
+
+Fix this by converting && to ||
+
+This issue was detected with the help of Coccinelle, and audited and
+fixed manually.
+
+Fixes: 1a0d0d5ed5e3 ("powerpc/vas: Add platform specific user window operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20211015050345.GA1161918@embeddedor
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/book3s/vas-api.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/book3s/vas-api.c
++++ b/arch/powerpc/platforms/book3s/vas-api.c
+@@ -303,7 +303,7 @@ static int coproc_ioc_tx_win_open(struct
+ return -EINVAL;
+ }
+
+- if (!cp_inst->coproc->vops && !cp_inst->coproc->vops->open_win) {
++ if (!cp_inst->coproc->vops || !cp_inst->coproc->vops->open_win) {
+ pr_err("VAS API is not registered\n");
+ return -EACCES;
+ }
+@@ -373,7 +373,7 @@ static int coproc_mmap(struct file *fp,
+ return -EINVAL;
+ }
+
+- if (!cp_inst->coproc->vops && !cp_inst->coproc->vops->paste_addr) {
++ if (!cp_inst->coproc->vops || !cp_inst->coproc->vops->paste_addr) {
+ pr_err("%s(): VAS API is not registered\n", __func__);
+ return -EACCES;
+ }
remoteproc-fix-the-wrong-default-value-of-is_iomem.patch
remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch
remoteproc-imx_rproc-fix-rsc-table-name.patch
+mtd-rawnand-fsmc-fix-use-of-sm-order.patch
+mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-mpc5121-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-gpio-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-orion-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-plat_nand-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch
+powerpc-vas-fix-potential-null-pointer-dereference.patch
+powerpc-bpf-fix-write-protecting-jit-code.patch
+powerpc-32e-ignore-esr-in-instruction-storage-interrupt-handler.patch
+powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch
+powerpc-security-use-a-mutex-for-interrupt-exit-code-patching.patch
+powerpc-64s-interrupt-fix-check_return_regs_valid-false-positive.patch
+powerpc-pseries-mobility-ignore-ibm-platform-facilities-updates.patch
+powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch
+drm-sun4i-fix-macros-in-sun8i_csc.h.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
