--- /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(-)
+
+diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.h b/drivers/gpu/drm/sun4i/sun8i_csc.h
+index a55a38ad849c..022cafa6c06c 100644
+--- 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)
+
+--
+2.33.1
+
--- /dev/null
+From 313c84b5ae4104e48c661d5d706f9f4c425fd50f Mon Sep 17 00:00:00 2001
+From: Jack Andersen <jackoalan@gmail.com>
+Date: Mon, 18 Oct 2021 13:25:41 +0200
+Subject: mfd: dln2: Add cell for initializing DLN2 ADC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Jack Andersen <jackoalan@gmail.com>
+
+commit 313c84b5ae4104e48c661d5d706f9f4c425fd50f upstream.
+
+This patch extends the DLN2 driver; adding cell for adc_dln2 module.
+
+The original patch[1] fell through the cracks when the driver was added
+so ADC has never actually been usable. That patch did not have ACPI
+support which was added in v5.9, so the oldest supported version this
+current patch can be backported to is 5.10.
+
+[1] https://www.spinics.net/lists/linux-iio/msg33975.html
+
+Cc: <stable@vger.kernel.org> # 5.10+
+Signed-off-by: Jack Andersen <jackoalan@gmail.com>
+Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Link: https://lore.kernel.org/r/20211018112541.25466-1-noralf@tronnes.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mfd/dln2.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+--- a/drivers/mfd/dln2.c
++++ b/drivers/mfd/dln2.c
+@@ -50,6 +50,7 @@ enum dln2_handle {
+ DLN2_HANDLE_GPIO,
+ DLN2_HANDLE_I2C,
+ DLN2_HANDLE_SPI,
++ DLN2_HANDLE_ADC,
+ DLN2_HANDLES
+ };
+
+@@ -653,6 +654,7 @@ enum {
+ DLN2_ACPI_MATCH_GPIO = 0,
+ DLN2_ACPI_MATCH_I2C = 1,
+ DLN2_ACPI_MATCH_SPI = 2,
++ DLN2_ACPI_MATCH_ADC = 3,
+ };
+
+ static struct dln2_platform_data dln2_pdata_gpio = {
+@@ -683,6 +685,16 @@ static struct mfd_cell_acpi_match dln2_a
+ .adr = DLN2_ACPI_MATCH_SPI,
+ };
+
++/* Only one ADC port supported */
++static struct dln2_platform_data dln2_pdata_adc = {
++ .handle = DLN2_HANDLE_ADC,
++ .port = 0,
++};
++
++static struct mfd_cell_acpi_match dln2_acpi_match_adc = {
++ .adr = DLN2_ACPI_MATCH_ADC,
++};
++
+ static const struct mfd_cell dln2_devs[] = {
+ {
+ .name = "dln2-gpio",
+@@ -702,6 +714,12 @@ static const struct mfd_cell dln2_devs[]
+ .platform_data = &dln2_pdata_spi,
+ .pdata_size = sizeof(struct dln2_platform_data),
+ },
++ {
++ .name = "dln2-adc",
++ .acpi_match = &dln2_acpi_match_adc,
++ .platform_data = &dln2_pdata_adc,
++ .pdata_size = sizeof(struct dln2_platform_data),
++ },
+ };
+
+ static void dln2_stop(struct dln2_dev *dln2)
--- /dev/null
+From 60e2793d440a3ec95abb5d6d4fc034a4b480472d Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Fri, 5 Nov 2021 13:38:06 -0700
+Subject: mm, oom: do not trigger out_of_memory from the #PF
+
+From: Michal Hocko <mhocko@suse.com>
+
+commit 60e2793d440a3ec95abb5d6d4fc034a4b480472d upstream.
+
+Any allocation failure during the #PF path will return with VM_FAULT_OOM
+which in turn results in pagefault_out_of_memory. This can happen for 2
+different reasons. a) Memcg is out of memory and we rely on
+mem_cgroup_oom_synchronize to perform the memcg OOM handling or b)
+normal allocation fails.
+
+The latter is quite problematic because allocation paths already trigger
+out_of_memory and the page allocator tries really hard to not fail
+allocations. Anyway, if the OOM killer has been already invoked there
+is no reason to invoke it again from the #PF path. Especially when the
+OOM condition might be gone by that time and we have no way to find out
+other than allocate.
+
+Moreover if the allocation failed and the OOM killer hasn't been invoked
+then we are unlikely to do the right thing from the #PF context because
+we have already lost the allocation context and restictions and
+therefore might oom kill a task from a different NUMA domain.
+
+This all suggests that there is no legitimate reason to trigger
+out_of_memory from pagefault_out_of_memory so drop it. Just to be sure
+that no #PF path returns with VM_FAULT_OOM without allocation print a
+warning that this is happening before we restart the #PF.
+
+[VvS: #PF allocation can hit into limit of cgroup v1 kmem controller.
+This is a local problem related to memcg, however, it causes unnecessary
+global OOM kills that are repeated over and over again and escalate into a
+real disaster. This has been broken since kmem accounting has been
+introduced for cgroup v1 (3.8). There was no kmem specific reclaim for
+the separate limit so the only way to handle kmem hard limit was to return
+with ENOMEM. In upstream the problem will be fixed by removing the
+outdated kmem limit, however stable and LTS kernels cannot do it and are
+still affected. This patch fixes the problem and should be backported
+into stable/LTS.]
+
+Link: https://lkml.kernel.org/r/f5fd8dd8-0ad4-c524-5f65-920b01972a42@virtuozzo.com
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Roman Gushchin <guro@fb.com>
+Cc: Shakeel Butt <shakeelb@google.com>
+Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Cc: Uladzislau Rezki <urezki@gmail.com>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/oom_kill.c | 22 ++++++++--------------
+ 1 file changed, 8 insertions(+), 14 deletions(-)
+
+--- a/mm/oom_kill.c
++++ b/mm/oom_kill.c
+@@ -1118,19 +1118,15 @@ bool out_of_memory(struct oom_control *o
+ }
+
+ /*
+- * The pagefault handler calls here because it is out of memory, so kill a
+- * memory-hogging task. If oom_lock is held by somebody else, a parallel oom
+- * killing is already in progress so do nothing.
++ * The pagefault handler calls here because some allocation has failed. We have
++ * to take care of the memcg OOM here because this is the only safe context without
++ * any locks held but let the oom killer triggered from the allocation context care
++ * about the global OOM.
+ */
+ void pagefault_out_of_memory(void)
+ {
+- struct oom_control oc = {
+- .zonelist = NULL,
+- .nodemask = NULL,
+- .memcg = NULL,
+- .gfp_mask = 0,
+- .order = 0,
+- };
++ static DEFINE_RATELIMIT_STATE(pfoom_rs, DEFAULT_RATELIMIT_INTERVAL,
++ DEFAULT_RATELIMIT_BURST);
+
+ if (mem_cgroup_oom_synchronize(true))
+ return;
+@@ -1138,8 +1134,6 @@ void pagefault_out_of_memory(void)
+ if (fatal_signal_pending(current))
+ return;
+
+- if (!mutex_trylock(&oom_lock))
+- return;
+- out_of_memory(&oc);
+- mutex_unlock(&oom_lock);
++ if (__ratelimit(&pfoom_rs))
++ pr_warn("Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF\n");
+ }
--- /dev/null
+From 0b28179a6138a5edd9d82ad2687c05b3773c387b Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Fri, 5 Nov 2021 13:38:02 -0700
+Subject: mm, oom: pagefault_out_of_memory: don't force global OOM for dying tasks
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit 0b28179a6138a5edd9d82ad2687c05b3773c387b upstream.
+
+Patch series "memcg: prohibit unconditional exceeding the limit of dying tasks", v3.
+
+Memory cgroup charging allows killed or exiting tasks to exceed the hard
+limit. It can be misused and allowed to trigger global OOM from inside
+a memcg-limited container. On the other hand if memcg fails allocation,
+called from inside #PF handler it triggers global OOM from inside
+pagefault_out_of_memory().
+
+To prevent these problems this patchset:
+ (a) removes execution of out_of_memory() from
+ pagefault_out_of_memory(), becasue nobody can explain why it is
+ necessary.
+ (b) allow memcg to fail allocation of dying/killed tasks.
+
+This patch (of 3):
+
+Any allocation failure during the #PF path will return with VM_FAULT_OOM
+which in turn results in pagefault_out_of_memory which in turn executes
+out_out_memory() and can kill a random task.
+
+An allocation might fail when the current task is the oom victim and
+there are no memory reserves left. The OOM killer is already handled at
+the page allocator level for the global OOM and at the charging level
+for the memcg one. Both have much more information about the scope of
+allocation/charge request. This means that either the OOM killer has
+been invoked properly and didn't lead to the allocation success or it
+has been skipped because it couldn't have been invoked. In both cases
+triggering it from here is pointless and even harmful.
+
+It makes much more sense to let the killed task die rather than to wake
+up an eternally hungry oom-killer and send him to choose a fatter victim
+for breakfast.
+
+Link: https://lkml.kernel.org/r/0828a149-786e-7c06-b70a-52d086818ea3@virtuozzo.com
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Suggested-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: Roman Gushchin <guro@fb.com>
+Cc: Shakeel Butt <shakeelb@google.com>
+Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
+Cc: Uladzislau Rezki <urezki@gmail.com>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/oom_kill.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/oom_kill.c
++++ b/mm/oom_kill.c
+@@ -1135,6 +1135,9 @@ void pagefault_out_of_memory(void)
+ if (mem_cgroup_oom_synchronize(true))
+ return;
+
++ if (fatal_signal_pending(current))
++ return;
++
+ if (!mutex_trylock(&oom_lock))
+ return;
+ out_of_memory(&oc);
--- /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
+@@ -238,9 +238,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;
+@@ -309,6 +308,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 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
+@@ -76,9 +76,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;
+@@ -155,6 +154,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 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 foo@baz Mon Nov 15 03:32:23 PM CET 2021
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Mon, 15 Nov 2021 16:36:30 +0530
+Subject: powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC
+To: <stable@vger.kernel.org>
+Cc: Michael Ellerman <mpe@ellerman.id.au>, Daniel Borkmann <daniel@iogearbox.net>
+Message-ID: <652222f2afd7dd5876a87e079c1c4b2530c3572c.1636963563.git.naveen.n.rao@linux.vnet.ibm.com>
+
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+
+upstream commit b7540d62509453263604a155bf2d5f0ed450cba2
+
+Emit similar instruction sequences to commit a048a07d7f4535
+("powerpc/64s: Add support for a store forwarding barrier at kernel
+entry/exit") when encountering BPF_NOSPEC.
+
+Mitigations are enabled depending on what the firmware advertises. In
+particular, we do not gate these mitigations based on current settings,
+just like in x86. Due to this, we don't need to take any action if
+mitigations are enabled or disabled at runtime.
+
+Signed-off-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/956570cbc191cd41f8274bed48ee757a86dac62a.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
+[adjust macros to account for commits 1c9debbc2eb539 and ef909ba954145e.
+adjust security feature checks to account for commit 84ed26fd00c514]
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/net/bpf_jit64.h | 8 ++---
+ arch/powerpc/net/bpf_jit_comp64.c | 56 +++++++++++++++++++++++++++++++++++---
+ 2 files changed, 56 insertions(+), 8 deletions(-)
+
+--- a/arch/powerpc/net/bpf_jit64.h
++++ b/arch/powerpc/net/bpf_jit64.h
+@@ -16,18 +16,18 @@
+ * with our redzone usage.
+ *
+ * [ prev sp ] <-------------
+- * [ nv gpr save area ] 6*8 |
++ * [ nv gpr save area ] 5*8 |
+ * [ tail_call_cnt ] 8 |
+- * [ local_tmp_var ] 8 |
++ * [ local_tmp_var ] 16 |
+ * fp (r31) --> [ ebpf stack space ] upto 512 |
+ * [ frame header ] 32/112 |
+ * sp (r1) ---> [ stack pointer ] --------------
+ */
+
+ /* for gpr non volatile registers BPG_REG_6 to 10 */
+-#define BPF_PPC_STACK_SAVE (6*8)
++#define BPF_PPC_STACK_SAVE (5*8)
+ /* for bpf JIT code internal usage */
+-#define BPF_PPC_STACK_LOCALS 16
++#define BPF_PPC_STACK_LOCALS 24
+ /* stack frame excluding BPF stack, ensure this is quadword aligned */
+ #define BPF_PPC_STACKFRAME (STACK_FRAME_MIN_SIZE + \
+ BPF_PPC_STACK_LOCALS + BPF_PPC_STACK_SAVE)
+--- a/arch/powerpc/net/bpf_jit_comp64.c
++++ b/arch/powerpc/net/bpf_jit_comp64.c
+@@ -15,6 +15,7 @@
+ #include <linux/if_vlan.h>
+ #include <asm/kprobes.h>
+ #include <linux/bpf.h>
++#include <asm/security_features.h>
+
+ #include "bpf_jit64.h"
+
+@@ -56,9 +57,9 @@ static inline bool bpf_has_stack_frame(s
+ * [ prev sp ] <-------------
+ * [ ... ] |
+ * sp (r1) ---> [ stack pointer ] --------------
+- * [ nv gpr save area ] 6*8
++ * [ nv gpr save area ] 5*8
+ * [ tail_call_cnt ] 8
+- * [ local_tmp_var ] 8
++ * [ local_tmp_var ] 16
+ * [ unused red zone ] 208 bytes protected
+ */
+ static int bpf_jit_stack_local(struct codegen_context *ctx)
+@@ -66,12 +67,12 @@ static int bpf_jit_stack_local(struct co
+ if (bpf_has_stack_frame(ctx))
+ return STACK_FRAME_MIN_SIZE + ctx->stack_size;
+ else
+- return -(BPF_PPC_STACK_SAVE + 16);
++ return -(BPF_PPC_STACK_SAVE + 24);
+ }
+
+ static int bpf_jit_stack_tailcallcnt(struct codegen_context *ctx)
+ {
+- return bpf_jit_stack_local(ctx) + 8;
++ return bpf_jit_stack_local(ctx) + 16;
+ }
+
+ static int bpf_jit_stack_offsetof(struct codegen_context *ctx, int reg)
+@@ -290,11 +291,34 @@ static int bpf_jit_emit_tail_call(u32 *i
+ return 0;
+ }
+
++/*
++ * We spill into the redzone always, even if the bpf program has its own stackframe.
++ * Offsets hardcoded based on BPF_PPC_STACK_SAVE -- see bpf_jit_stack_local()
++ */
++void bpf_stf_barrier(void);
++
++asm (
++" .global bpf_stf_barrier ;"
++" bpf_stf_barrier: ;"
++" std 21,-64(1) ;"
++" std 22,-56(1) ;"
++" sync ;"
++" ld 21,-64(1) ;"
++" ld 22,-56(1) ;"
++" ori 31,31,0 ;"
++" .rept 14 ;"
++" b 1f ;"
++" 1: ;"
++" .endr ;"
++" blr ;"
++);
++
+ /* Assemble the body code between the prologue & epilogue */
+ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
+ struct codegen_context *ctx,
+ u32 *addrs, bool extra_pass)
+ {
++ enum stf_barrier_type stf_barrier = stf_barrier_type_get();
+ const struct bpf_insn *insn = fp->insnsi;
+ int flen = fp->len;
+ int i, ret;
+@@ -665,6 +689,30 @@ emit_clear:
+ * BPF_ST NOSPEC (speculation barrier)
+ */
+ case BPF_ST | BPF_NOSPEC:
++ if (!security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) ||
++ (!security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) &&
++ (!security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV) || !cpu_has_feature(CPU_FTR_HVMODE))))
++ break;
++
++ switch (stf_barrier) {
++ case STF_BARRIER_EIEIO:
++ EMIT(0x7c0006ac | 0x02000000);
++ break;
++ case STF_BARRIER_SYNC_ORI:
++ EMIT(PPC_INST_SYNC);
++ EMIT(PPC_RAW_LD(b2p[TMP_REG_1], 13, 0));
++ EMIT(PPC_RAW_ORI(31, 31, 0));
++ break;
++ case STF_BARRIER_FALLBACK:
++ EMIT(PPC_INST_MFLR | ___PPC_RT(b2p[TMP_REG_1]));
++ PPC_LI64(12, dereference_kernel_function_descriptor(bpf_stf_barrier));
++ EMIT(PPC_RAW_MTCTR(12));
++ EMIT(PPC_INST_BCTR | 0x1);
++ EMIT(PPC_RAW_MTLR(b2p[TMP_REG_1]));
++ break;
++ case STF_BARRIER_NONE:
++ break;
++ }
+ break;
+
+ /*
--- /dev/null
+From foo@baz Mon Nov 15 03:32:23 PM CET 2021
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Mon, 15 Nov 2021 16:36:28 +0530
+Subject: powerpc/bpf: Validate branch ranges
+To: <stable@vger.kernel.org>
+Cc: Michael Ellerman <mpe@ellerman.id.au>, Daniel Borkmann <daniel@iogearbox.net>
+Message-ID: <04c4551456c61cc9df757d9bd2c9b0f9523845ae.1636963563.git.naveen.n.rao@linux.vnet.ibm.com>
+
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+
+upstream commit 3832ba4e283d7052b783dab8311df7e3590fed93
+
+Add checks to ensure that we never emit branch instructions with
+truncated branch offsets.
+
+Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Tested-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Acked-by: Song Liu <songliubraving@fb.com>
+Acked-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/71d33a6b7603ec1013c9734dd8bdd4ff5e929142.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
+[drop ppc32 changes]
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/net/bpf_jit.h | 26 ++++++++++++++++++++------
+ arch/powerpc/net/bpf_jit_comp64.c | 8 ++++++--
+ 2 files changed, 26 insertions(+), 8 deletions(-)
+
+--- a/arch/powerpc/net/bpf_jit.h
++++ b/arch/powerpc/net/bpf_jit.h
+@@ -12,6 +12,7 @@
+
+ #include <asm/types.h>
+ #include <asm/ppc-opcode.h>
++#include <asm/code-patching.h>
+
+ #ifdef PPC64_ELF_ABI_v1
+ #define FUNCTION_DESCR_SIZE 24
+@@ -24,13 +25,26 @@
+ #define EMIT(instr) PLANT_INSTR(image, ctx->idx, instr)
+
+ /* Long jump; (unconditional 'branch') */
+-#define PPC_JMP(dest) EMIT(PPC_INST_BRANCH | \
+- (((dest) - (ctx->idx * 4)) & 0x03fffffc))
++#define PPC_JMP(dest) \
++ do { \
++ long offset = (long)(dest) - (ctx->idx * 4); \
++ if (!is_offset_in_branch_range(offset)) { \
++ pr_err_ratelimited("Branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \
++ return -ERANGE; \
++ } \
++ EMIT(PPC_INST_BRANCH | (offset & 0x03fffffc)); \
++ } while (0)
+ /* "cond" here covers BO:BI fields. */
+-#define PPC_BCC_SHORT(cond, dest) EMIT(PPC_INST_BRANCH_COND | \
+- (((cond) & 0x3ff) << 16) | \
+- (((dest) - (ctx->idx * 4)) & \
+- 0xfffc))
++#define PPC_BCC_SHORT(cond, dest) \
++ do { \
++ long offset = (long)(dest) - (ctx->idx * 4); \
++ if (!is_offset_in_cond_branch_range(offset)) { \
++ pr_err_ratelimited("Conditional branch offset 0x%lx (@%u) out of range\n", offset, ctx->idx); \
++ return -ERANGE; \
++ } \
++ EMIT(PPC_INST_BRANCH_COND | (((cond) & 0x3ff) << 16) | (offset & 0xfffc)); \
++ } while (0)
++
+ /* Sign-extended 32-bit immediate load */
+ #define PPC_LI32(d, i) do { \
+ if ((int)(uintptr_t)(i) >= -32768 && \
+--- a/arch/powerpc/net/bpf_jit_comp64.c
++++ b/arch/powerpc/net/bpf_jit_comp64.c
+@@ -224,7 +224,7 @@ static void bpf_jit_emit_func_call_rel(u
+ EMIT(PPC_RAW_BLRL());
+ }
+
+-static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
++static int bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32 out)
+ {
+ /*
+ * By now, the eBPF program has already setup parameters in r3, r4 and r5
+@@ -285,7 +285,9 @@ static void bpf_jit_emit_tail_call(u32 *
+ bpf_jit_emit_common_epilogue(image, ctx);
+
+ EMIT(PPC_RAW_BCTR());
++
+ /* out: */
++ return 0;
+ }
+
+ /* Assemble the body code between the prologue & epilogue */
+@@ -1010,7 +1012,9 @@ cond_branch:
+ */
+ case BPF_JMP | BPF_TAIL_CALL:
+ ctx->seen |= SEEN_TAILCALL;
+- bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
++ ret = bpf_jit_emit_tail_call(image, ctx, addrs[i + 1]);
++ if (ret < 0)
++ return ret;
+ break;
+
+ default:
--- /dev/null
+From foo@baz Mon Nov 15 03:32:23 PM CET 2021
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Mon, 15 Nov 2021 16:36:27 +0530
+Subject: powerpc/lib: Add helper to check if offset is within conditional branch range
+To: <stable@vger.kernel.org>
+Cc: Michael Ellerman <mpe@ellerman.id.au>, Daniel Borkmann <daniel@iogearbox.net>
+Message-ID: <a72fee822b7a7da19a5afbf2609d475cf802dae8.1636963563.git.naveen.n.rao@linux.vnet.ibm.com>
+
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+
+upstream commit 4549c3ea3160fa8b3f37dfe2f957657bb265eda9
+
+Add a helper to check if a given offset is within the branch range for a
+powerpc conditional branch instruction, and update some sites to use the
+new helper.
+
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
+Acked-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/442b69a34ced32ca346a0d9a855f3f6cfdbbbd41.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/include/asm/code-patching.h | 1 +
+ arch/powerpc/lib/code-patching.c | 7 ++++++-
+ arch/powerpc/net/bpf_jit.h | 7 +------
+ 3 files changed, 8 insertions(+), 7 deletions(-)
+
+--- a/arch/powerpc/include/asm/code-patching.h
++++ b/arch/powerpc/include/asm/code-patching.h
+@@ -23,6 +23,7 @@
+ #define BRANCH_ABSOLUTE 0x2
+
+ bool is_offset_in_branch_range(long offset);
++bool is_offset_in_cond_branch_range(long offset);
+ int create_branch(struct ppc_inst *instr, const struct ppc_inst *addr,
+ unsigned long target, int flags);
+ int create_cond_branch(struct ppc_inst *instr, const struct ppc_inst *addr,
+--- a/arch/powerpc/lib/code-patching.c
++++ b/arch/powerpc/lib/code-patching.c
+@@ -230,6 +230,11 @@ bool is_offset_in_branch_range(long offs
+ return (offset >= -0x2000000 && offset <= 0x1fffffc && !(offset & 0x3));
+ }
+
++bool is_offset_in_cond_branch_range(long offset)
++{
++ return offset >= -0x8000 && offset <= 0x7fff && !(offset & 0x3);
++}
++
+ /*
+ * Helper to check if a given instruction is a conditional branch
+ * Derived from the conditional checks in analyse_instr()
+@@ -283,7 +288,7 @@ int create_cond_branch(struct ppc_inst *
+ offset = offset - (unsigned long)addr;
+
+ /* Check we can represent the target in the instruction format */
+- if (offset < -0x8000 || offset > 0x7FFF || offset & 0x3)
++ if (!is_offset_in_cond_branch_range(offset))
+ return 1;
+
+ /* Mask out the flags and target, so they don't step on each other. */
+--- a/arch/powerpc/net/bpf_jit.h
++++ b/arch/powerpc/net/bpf_jit.h
+@@ -71,11 +71,6 @@
+ #define PPC_FUNC_ADDR(d,i) do { PPC_LI32(d, i); } while(0)
+ #endif
+
+-static inline bool is_nearbranch(int offset)
+-{
+- return (offset < 32768) && (offset >= -32768);
+-}
+-
+ /*
+ * The fly in the ointment of code size changing from pass to pass is
+ * avoided by padding the short branch case with a NOP. If code size differs
+@@ -84,7 +79,7 @@ static inline bool is_nearbranch(int off
+ * state.
+ */
+ #define PPC_BCC(cond, dest) do { \
+- if (is_nearbranch((dest) - (ctx->idx * 4))) { \
++ if (is_offset_in_cond_branch_range((long)(dest) - (ctx->idx * 4))) { \
+ PPC_BCC_SHORT(cond, dest); \
+ EMIT(PPC_RAW_NOP()); \
+ } else { \
--- /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
+@@ -372,6 +372,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;
+@@ -393,9 +399,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;
+ }
+
+@@ -404,6 +411,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;
+ }
+
+@@ -414,6 +423,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 foo@baz Mon Nov 15 03:32:23 PM CET 2021
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Mon, 15 Nov 2021 16:36:29 +0530
+Subject: powerpc/security: Add a helper to query stf_barrier type
+To: <stable@vger.kernel.org>
+Cc: Michael Ellerman <mpe@ellerman.id.au>, Daniel Borkmann <daniel@iogearbox.net>
+Message-ID: <924e967ed8ed2dfcc748eab13cb86e22f3a72afe.1636963563.git.naveen.n.rao@linux.vnet.ibm.com>
+
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+
+upstream commit 030905920f32e91a52794937f67434ac0b3ea41a
+
+Add a helper to return the stf_barrier type for the current processor.
+
+Signed-off-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/3bd5d7f96ea1547991ac2ce3137dc2b220bae285.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/include/asm/security_features.h | 5 +++++
+ arch/powerpc/kernel/security.c | 5 +++++
+ 2 files changed, 10 insertions(+)
+
+--- a/arch/powerpc/include/asm/security_features.h
++++ b/arch/powerpc/include/asm/security_features.h
+@@ -39,6 +39,11 @@ static inline bool security_ftr_enabled(
+ return !!(powerpc_security_features & feature);
+ }
+
++#ifdef CONFIG_PPC_BOOK3S_64
++enum stf_barrier_type stf_barrier_type_get(void);
++#else
++static inline enum stf_barrier_type stf_barrier_type_get(void) { return STF_BARRIER_NONE; }
++#endif
+
+ // Features indicating support for Spectre/Meltdown mitigations
+
+--- a/arch/powerpc/kernel/security.c
++++ b/arch/powerpc/kernel/security.c
+@@ -261,6 +261,11 @@ static int __init handle_no_stf_barrier(
+
+ early_param("no_stf_barrier", handle_no_stf_barrier);
+
++enum stf_barrier_type stf_barrier_type_get(void)
++{
++ return stf_enabled_flush_types;
++}
++
+ /* This is the generic flag used by other architectures */
+ static int __init handle_ssbd(char *p)
+ {
--- /dev/null
+From 3826350e6dd435e244eb6e47abad5a47c169ebc2 Mon Sep 17 00:00:00 2001
+From: Harald Freudenberger <freude@linux.ibm.com>
+Date: Thu, 14 Oct 2021 09:58:24 +0200
+Subject: s390/ap: Fix hanging ioctl caused by orphaned replies
+
+From: Harald Freudenberger <freude@linux.ibm.com>
+
+commit 3826350e6dd435e244eb6e47abad5a47c169ebc2 upstream.
+
+When a queue is switched to soft offline during heavy load and later
+switched to soft online again and now used, it may be that the caller
+is blocked forever in the ioctl call.
+
+The failure occurs because there is a pending reply after the queue(s)
+have been switched to offline. This orphaned reply is received when
+the queue is switched to online and is accidentally counted for the
+outstanding replies. So when there was a valid outstanding reply and
+this orphaned reply is received it counts as the outstanding one thus
+dropping the outstanding counter to 0. Voila, with this counter the
+receive function is not called any more and the real outstanding reply
+is never received (until another request comes in...) and the ioctl
+blocks.
+
+The fix is simple. However, instead of readjusting the counter when an
+orphaned reply is detected, I check the queue status for not empty and
+compare this to the outstanding counter. So if the queue is not empty
+then the counter must not drop to 0 but at least have a value of 1.
+
+Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/crypto/ap_queue.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/s390/crypto/ap_queue.c
++++ b/drivers/s390/crypto/ap_queue.c
+@@ -142,6 +142,8 @@ static struct ap_queue_status ap_sm_recv
+ switch (status.response_code) {
+ case AP_RESPONSE_NORMAL:
+ aq->queue_count = max_t(int, 0, aq->queue_count - 1);
++ if (!status.queue_empty && !aq->queue_count)
++ aq->queue_count++;
+ if (aq->queue_count > 0)
+ mod_timer(&aq->timeout,
+ jiffies + aq->request_timeout);
--- /dev/null
+From a4751f157c194431fae9e9c493f456df8272b871 Mon Sep 17 00:00:00 2001
+From: Vineeth Vijayan <vneethv@linux.ibm.com>
+Date: Fri, 5 Nov 2021 16:44:51 +0100
+Subject: s390/cio: check the subchannel validity for dev_busid
+
+From: Vineeth Vijayan <vneethv@linux.ibm.com>
+
+commit a4751f157c194431fae9e9c493f456df8272b871 upstream.
+
+Check the validity of subchanel before reading other fields in
+the schib.
+
+Fixes: d3683c055212 ("s390/cio: add dev_busid sysfs entry for each subchannel")
+CC: <stable@vger.kernel.org>
+Reported-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
+Reviewed-by: Cornelia Huck <cohuck@redhat.com>
+Link: https://lore.kernel.org/r/20211105154451.847288-1-vneethv@linux.ibm.com
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/cio/css.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/cio/css.c
++++ b/drivers/s390/cio/css.c
+@@ -433,8 +433,8 @@ static ssize_t dev_busid_show(struct dev
+ struct subchannel *sch = to_subchannel(dev);
+ struct pmcw *pmcw = &sch->schib.pmcw;
+
+- if ((pmcw->st == SUBCHANNEL_TYPE_IO ||
+- pmcw->st == SUBCHANNEL_TYPE_MSG) && pmcw->dnv)
++ if ((pmcw->st == SUBCHANNEL_TYPE_IO && pmcw->dnv) ||
++ (pmcw->st == SUBCHANNEL_TYPE_MSG && pmcw->w))
+ return sysfs_emit(buf, "0.%x.%04x\n", sch->schid.ssid,
+ pmcw->dev);
+ else
--- /dev/null
+From ad9a14517263a16af040598c7920c09ca9670a31 Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Wed, 8 Sep 2021 17:36:23 +0200
+Subject: s390/cio: make ccw_device_dma_* more robust
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit ad9a14517263a16af040598c7920c09ca9670a31 upstream.
+
+Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
+classic notifiers") we were supposed to make sure that
+virtio_ccw_release_dev() completes before the ccw device and the
+attached dma pool are torn down, but unfortunately we did not. Before
+that commit it used to be OK to delay cleaning up the memory allocated
+by virtio-ccw indefinitely (which isn't really intuitive for guys used
+to destruction happens in reverse construction order), but now we
+trigger a BUG_ON if the genpool is destroyed before all memory allocated
+from it is deallocated. Which brings down the guest. We can observe this
+problem, when unregister_virtio_device() does not give up the last
+reference to the virtio_device (e.g. because a virtio-scsi attached scsi
+disk got removed without previously unmounting its previously mounted
+partition).
+
+To make sure that the genpool is only destroyed after all the necessary
+freeing is done let us take a reference on the ccw device on each
+ccw_device_dma_zalloc() and give it up on each ccw_device_dma_free().
+
+Actually there are multiple approaches to fixing the problem at hand
+that can work. The upside of this one is that it is the safest one while
+remaining simple. We don't crash the guest even if the driver does not
+pair allocations and frees. The downside is the reference counting
+overhead, that the reference counting for ccw devices becomes more
+complex, in a sense that we need to pair the calls to the aforementioned
+functions for it to be correct, and that if we happen to leak, we leak
+more than necessary (the whole ccw device instead of just the genpool).
+
+Some alternatives to this approach are taking a reference in
+virtio_ccw_online() and giving it up in virtio_ccw_release_dev() or
+making sure virtio_ccw_release_dev() completes its work before
+virtio_ccw_remove() returns. The downside of these approaches is that
+these are less safe against programming errors.
+
+Cc: <stable@vger.kernel.org> # v5.3
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and classic notifiers")
+Reported-by: bfu@redhat.com
+Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
+Acked-by: Cornelia Huck <cohuck@redhat.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/cio/device_ops.c | 12 +++++++++++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/cio/device_ops.c
++++ b/drivers/s390/cio/device_ops.c
+@@ -825,13 +825,23 @@ EXPORT_SYMBOL_GPL(ccw_device_get_chid);
+ */
+ void *ccw_device_dma_zalloc(struct ccw_device *cdev, size_t size)
+ {
+- return cio_gp_dma_zalloc(cdev->private->dma_pool, &cdev->dev, size);
++ void *addr;
++
++ if (!get_device(&cdev->dev))
++ return NULL;
++ addr = cio_gp_dma_zalloc(cdev->private->dma_pool, &cdev->dev, size);
++ if (IS_ERR_OR_NULL(addr))
++ put_device(&cdev->dev);
++ return addr;
+ }
+ EXPORT_SYMBOL(ccw_device_dma_zalloc);
+
+ void ccw_device_dma_free(struct ccw_device *cdev, void *cpu_addr, size_t size)
+ {
++ if (!cpu_addr)
++ return;
+ cio_gp_dma_free(cdev->private->dma_pool, cpu_addr, size);
++ put_device(&cdev->dev);
+ }
+ EXPORT_SYMBOL(ccw_device_dma_free);
+
--- /dev/null
+From 213fca9e23b59581c573d558aa477556f00b8198 Mon Sep 17 00:00:00 2001
+From: Sven Schnelle <svens@linux.ibm.com>
+Date: Tue, 2 Nov 2021 10:55:30 +0100
+Subject: s390/tape: fix timer initialization in tape_std_assign()
+
+From: Sven Schnelle <svens@linux.ibm.com>
+
+commit 213fca9e23b59581c573d558aa477556f00b8198 upstream.
+
+commit 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor
+of timer_setup_on_stack()") changed the timer setup from
+init_timer_on_stack(() to timer_setup(), but missed to change the
+mod_timer() call. And while at it, use msecs_to_jiffies() instead
+of the open coded timeout calculation.
+
+Cc: stable@vger.kernel.org
+Fixes: 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()")
+Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
+Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/char/tape_std.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/s390/char/tape_std.c
++++ b/drivers/s390/char/tape_std.c
+@@ -53,7 +53,6 @@ int
+ tape_std_assign(struct tape_device *device)
+ {
+ int rc;
+- struct timer_list timeout;
+ struct tape_request *request;
+
+ request = tape_alloc_request(2, 11);
+@@ -70,7 +69,7 @@ tape_std_assign(struct tape_device *devi
+ * So we set up a timeout for this call.
+ */
+ timer_setup(&request->timer, tape_std_assign_timeout, 0);
+- mod_timer(&timeout, jiffies + 2 * HZ);
++ mod_timer(&request->timer, jiffies + msecs_to_jiffies(2000));
+
+ rc = tape_do_io_interruptible(device, request);
+
net-neigh-enable-state-migration-between-nud_permane.patch
9p-net-fix-missing-error-check-in-p9_check_errors.patch
memcg-prohibit-unconditional-exceeding-the-limit-of-dying-tasks.patch
+powerpc-lib-add-helper-to-check-if-offset-is-within-conditional-branch-range.patch
+powerpc-bpf-validate-branch-ranges.patch
+powerpc-security-add-a-helper-to-query-stf_barrier-type.patch
+powerpc-bpf-emit-stf-barrier-instruction-sequences-for-bpf_nospec.patch
+mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch
+mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch
+mfd-dln2-add-cell-for-initializing-dln2-adc.patch
+video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch
+s390-cio-check-the-subchannel-validity-for-dev_busid.patch
+s390-tape-fix-timer-initialization-in-tape_std_assign.patch
+s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch
+s390-cio-make-ccw_device_dma_-more-robust.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-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch
+powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch
+drm-sun4i-fix-macros-in-sun8i_csc.h.patch
--- /dev/null
+From 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+Date: Tue, 21 Sep 2021 19:35:06 +0200
+Subject: video: backlight: Drop maximum brightness override for brightness zero
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Vasut <marex@denx.de>
+
+commit 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa upstream.
+
+The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
+in backlight.c") says that gpio-backlight uses brightness as power state.
+This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight:
+Correct initial power state handling") and other backlight drivers do not
+require this workaround. Drop the workaround.
+
+This fixes the case where e.g. pwm-backlight can perfectly well be set to
+brightness 0 on boot in DT, which without this patch leads to the display
+brightness to be max instead of off.
+
+Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c")
+Cc: <stable@vger.kernel.org> # 5.4+
+Cc: <stable@vger.kernel.org> # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling
+Signed-off-by: Marek Vasut <marex@denx.de>
+Acked-by: Noralf Trønnes <noralf@tronnes.org>
+Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/backlight/backlight.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/drivers/video/backlight/backlight.c
++++ b/drivers/video/backlight/backlight.c
+@@ -688,12 +688,6 @@ static struct backlight_device *of_find_
+ of_node_put(np);
+ if (!bd)
+ return ERR_PTR(-EPROBE_DEFER);
+- /*
+- * Note: gpio_backlight uses brightness as
+- * power state during probe
+- */
+- if (!bd->props.brightness)
+- bd->props.brightness = bd->props.max_brightness;
+ }
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
