From: Greg Kroah-Hartman Date: Mon, 15 Nov 2021 15:05:55 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v5.4.160~37 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9f767106cc3005ef09178c30fb30333240eb52c2;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: drm-sun4i-fix-macros-in-sun8i_csc.h.patch mfd-dln2-add-cell-for-initializing-dln2-adc.patch mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch mtd-rawnand-au1550nd-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-mpc5121-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-pasemi-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-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch powerpc-bpf-emit-stf-barrier-instruction-sequences-for-bpf_nospec.patch powerpc-bpf-validate-branch-ranges.patch powerpc-lib-add-helper-to-check-if-offset-is-within-conditional-branch-range.patch powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch powerpc-security-add-a-helper-to-query-stf_barrier-type.patch s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch s390-cio-check-the-subchannel-validity-for-dev_busid.patch s390-cio-make-ccw_device_dma_-more-robust.patch s390-tape-fix-timer-initialization-in-tape_std_assign.patch video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch --- diff --git a/queue-5.10/drm-sun4i-fix-macros-in-sun8i_csc.h.patch b/queue-5.10/drm-sun4i-fix-macros-in-sun8i_csc.h.patch new file mode 100644 index 00000000000..9310ff75c23 --- /dev/null +++ b/queue-5.10/drm-sun4i-fix-macros-in-sun8i_csc.h.patch @@ -0,0 +1,50 @@ +From c302c98da646409d657a473da202f10f417f3ff1 Mon Sep 17 00:00:00 2001 +From: Jernej Skrabec +Date: Tue, 31 Aug 2021 20:48:19 +0200 +Subject: drm/sun4i: Fix macros in sun8i_csc.h + +From: Jernej Skrabec + +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 +Signed-off-by: Jernej Skrabec +Reviewed-by: Chen-Yu Tsai +Signed-off-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20210831184819.93670-1-jernej.skrabec@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-5.10/mfd-dln2-add-cell-for-initializing-dln2-adc.patch b/queue-5.10/mfd-dln2-add-cell-for-initializing-dln2-adc.patch new file mode 100644 index 00000000000..2399b41a44f --- /dev/null +++ b/queue-5.10/mfd-dln2-add-cell-for-initializing-dln2-adc.patch @@ -0,0 +1,79 @@ +From 313c84b5ae4104e48c661d5d706f9f4c425fd50f Mon Sep 17 00:00:00 2001 +From: Jack Andersen +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 + +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: # 5.10+ +Signed-off-by: Jack Andersen +Signed-off-by: Noralf Trønnes +Signed-off-by: Lee Jones +Link: https://lore.kernel.org/r/20211018112541.25466-1-noralf@tronnes.org +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch b/queue-5.10/mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch new file mode 100644 index 00000000000..5b231786836 --- /dev/null +++ b/queue-5.10/mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch @@ -0,0 +1,102 @@ +From 60e2793d440a3ec95abb5d6d4fc034a4b480472d Mon Sep 17 00:00:00 2001 +From: Michal Hocko +Date: Fri, 5 Nov 2021 13:38:06 -0700 +Subject: mm, oom: do not trigger out_of_memory from the #PF + +From: Michal Hocko + +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 +Signed-off-by: Vasily Averin +Acked-by: Michal Hocko +Cc: Johannes Weiner +Cc: Mel Gorman +Cc: Roman Gushchin +Cc: Shakeel Butt +Cc: Tetsuo Handa +Cc: Uladzislau Rezki +Cc: Vladimir Davydov +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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"); + } diff --git a/queue-5.10/mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch b/queue-5.10/mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch new file mode 100644 index 00000000000..a0cfefb7007 --- /dev/null +++ b/queue-5.10/mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch @@ -0,0 +1,74 @@ +From 0b28179a6138a5edd9d82ad2687c05b3773c387b Mon Sep 17 00:00:00 2001 +From: Vasily Averin +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 + +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 +Suggested-by: Michal Hocko +Acked-by: Michal Hocko +Cc: Johannes Weiner +Cc: Mel Gorman +Cc: Roman Gushchin +Cc: Shakeel Butt +Cc: Tetsuo Handa +Cc: Uladzislau Rezki +Cc: Vladimir Davydov +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..4c5127b3410 --- /dev/null +++ b/queue-5.10/mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..426bf31f6bd --- /dev/null +++ b/queue-5.10/mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From 7e3cdba176ba59eaf4d463d273da0718e3626140 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/mtd-rawnand-gpio-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-gpio-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..457d2c02cc5 --- /dev/null +++ b/queue-5.10/mtd-rawnand-gpio-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/mtd-rawnand-mpc5121-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-mpc5121-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..ac637350e3f --- /dev/null +++ b/queue-5.10/mtd-rawnand-mpc5121-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-5.10/mtd-rawnand-orion-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-orion-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..0a72edef9ec --- /dev/null +++ b/queue-5.10/mtd-rawnand-orion-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From 194ac63de6ff56d30c48e3ac19c8a412f9c1408e Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.10/mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..edb723f3d78 --- /dev/null +++ b/queue-5.10/mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From f16b7d2a5e810fcf4b15d096246d0d445da9cc88 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/mtd-rawnand-plat_nand-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-plat_nand-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..8ad55468e3a --- /dev/null +++ b/queue-5.10/mtd-rawnand-plat_nand-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,71 @@ +From 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/mtd-rawnand-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.10/mtd-rawnand-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..4397f2df9f9 --- /dev/null +++ b/queue-5.10/mtd-rawnand-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch @@ -0,0 +1,74 @@ +From 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +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 + +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 +Cc: Kestrel seventyfour +Signed-off-by: Miquel Raynal +Tested-by: Jan Hoffmann +Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch b/queue-5.10/powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch new file mode 100644 index 00000000000..a5e418350db --- /dev/null +++ b/queue-5.10/powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch @@ -0,0 +1,137 @@ +From c45361abb9185b1e172bd75eff51ad5f601ccae4 Mon Sep 17 00:00:00 2001 +From: Xiaoming Ni +Date: Wed, 29 Sep 2021 11:36:46 +0800 +Subject: powerpc/85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n + +From: Xiaoming Ni + +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 +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20210929033646.39630-3-nixiaoming@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.10/powerpc-bpf-emit-stf-barrier-instruction-sequences-for-bpf_nospec.patch b/queue-5.10/powerpc-bpf-emit-stf-barrier-instruction-sequences-for-bpf_nospec.patch new file mode 100644 index 00000000000..75d7afa3816 --- /dev/null +++ b/queue-5.10/powerpc-bpf-emit-stf-barrier-instruction-sequences-for-bpf_nospec.patch @@ -0,0 +1,161 @@ +From foo@baz Mon Nov 15 03:32:23 PM CET 2021 +From: "Naveen N. Rao" +Date: Mon, 15 Nov 2021 16:36:30 +0530 +Subject: powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC +To: +Cc: Michael Ellerman , Daniel Borkmann +Message-ID: <652222f2afd7dd5876a87e079c1c4b2530c3572c.1636963563.git.naveen.n.rao@linux.vnet.ibm.com> + +From: "Naveen N. Rao" + +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 +Signed-off-by: Michael Ellerman +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #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; + + /* diff --git a/queue-5.10/powerpc-bpf-validate-branch-ranges.patch b/queue-5.10/powerpc-bpf-validate-branch-ranges.patch new file mode 100644 index 00000000000..abbae0c9cfe --- /dev/null +++ b/queue-5.10/powerpc-bpf-validate-branch-ranges.patch @@ -0,0 +1,106 @@ +From foo@baz Mon Nov 15 03:32:23 PM CET 2021 +From: "Naveen N. Rao" +Date: Mon, 15 Nov 2021 16:36:28 +0530 +Subject: powerpc/bpf: Validate branch ranges +To: +Cc: Michael Ellerman , Daniel Borkmann +Message-ID: <04c4551456c61cc9df757d9bd2c9b0f9523845ae.1636963563.git.naveen.n.rao@linux.vnet.ibm.com> + +From: "Naveen N. Rao" + +upstream commit 3832ba4e283d7052b783dab8311df7e3590fed93 + +Add checks to ensure that we never emit branch instructions with +truncated branch offsets. + +Suggested-by: Michael Ellerman +Signed-off-by: Naveen N. Rao +Tested-by: Johan Almbladh +Reviewed-by: Christophe Leroy +Acked-by: Song Liu +Acked-by: Johan Almbladh +Signed-off-by: Michael Ellerman +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include ++#include + + #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: diff --git a/queue-5.10/powerpc-lib-add-helper-to-check-if-offset-is-within-conditional-branch-range.patch b/queue-5.10/powerpc-lib-add-helper-to-check-if-offset-is-within-conditional-branch-range.patch new file mode 100644 index 00000000000..eca252ee1d7 --- /dev/null +++ b/queue-5.10/powerpc-lib-add-helper-to-check-if-offset-is-within-conditional-branch-range.patch @@ -0,0 +1,85 @@ +From foo@baz Mon Nov 15 03:32:23 PM CET 2021 +From: "Naveen N. Rao" +Date: Mon, 15 Nov 2021 16:36:27 +0530 +Subject: powerpc/lib: Add helper to check if offset is within conditional branch range +To: +Cc: Michael Ellerman , Daniel Borkmann +Message-ID: + +From: "Naveen N. Rao" + +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 +Reviewed-by: Christophe Leroy +Acked-by: Song Liu +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/442b69a34ced32ca346a0d9a855f3f6cfdbbbd41.1633464148.git.naveen.n.rao@linux.vnet.ibm.com +Signed-off-by: Naveen N. Rao +Signed-off-by: Greg Kroah-Hartman +--- + 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 { \ diff --git a/queue-5.10/powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch b/queue-5.10/powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch new file mode 100644 index 00000000000..4925542d06c --- /dev/null +++ b/queue-5.10/powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch @@ -0,0 +1,106 @@ +From 52862ab33c5d97490f3fa345d6529829e6d6637b Mon Sep 17 00:00:00 2001 +From: Vasant Hegde +Date: Thu, 28 Oct 2021 22:27:16 +0530 +Subject: powerpc/powernv/prd: Unregister OPAL_MSG_PRD2 notifier during module unload + +From: Vasant Hegde + +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 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 +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211028165716.41300-1-hegdevasant@linux.vnet.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.10/powerpc-security-add-a-helper-to-query-stf_barrier-type.patch b/queue-5.10/powerpc-security-add-a-helper-to-query-stf_barrier-type.patch new file mode 100644 index 00000000000..cc4a72eda52 --- /dev/null +++ b/queue-5.10/powerpc-security-add-a-helper-to-query-stf_barrier-type.patch @@ -0,0 +1,52 @@ +From foo@baz Mon Nov 15 03:32:23 PM CET 2021 +From: "Naveen N. Rao" +Date: Mon, 15 Nov 2021 16:36:29 +0530 +Subject: powerpc/security: Add a helper to query stf_barrier type +To: +Cc: Michael Ellerman , Daniel Borkmann +Message-ID: <924e967ed8ed2dfcc748eab13cb86e22f3a72afe.1636963563.git.naveen.n.rao@linux.vnet.ibm.com> + +From: "Naveen N. Rao" + +upstream commit 030905920f32e91a52794937f67434ac0b3ea41a + +Add a helper to return the stf_barrier type for the current processor. + +Signed-off-by: Naveen N. Rao +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/3bd5d7f96ea1547991ac2ce3137dc2b220bae285.1633464148.git.naveen.n.rao@linux.vnet.ibm.com +Signed-off-by: Naveen N. Rao +Signed-off-by: Greg Kroah-Hartman +--- + 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) + { diff --git a/queue-5.10/s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch b/queue-5.10/s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch new file mode 100644 index 00000000000..10c846ffb3e --- /dev/null +++ b/queue-5.10/s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch @@ -0,0 +1,47 @@ +From 3826350e6dd435e244eb6e47abad5a47c169ebc2 Mon Sep 17 00:00:00 2001 +From: Harald Freudenberger +Date: Thu, 14 Oct 2021 09:58:24 +0200 +Subject: s390/ap: Fix hanging ioctl caused by orphaned replies + +From: Harald Freudenberger + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/s390-cio-check-the-subchannel-validity-for-dev_busid.patch b/queue-5.10/s390-cio-check-the-subchannel-validity-for-dev_busid.patch new file mode 100644 index 00000000000..e846ae6ef7b --- /dev/null +++ b/queue-5.10/s390-cio-check-the-subchannel-validity-for-dev_busid.patch @@ -0,0 +1,37 @@ +From a4751f157c194431fae9e9c493f456df8272b871 Mon Sep 17 00:00:00 2001 +From: Vineeth Vijayan +Date: Fri, 5 Nov 2021 16:44:51 +0100 +Subject: s390/cio: check the subchannel validity for dev_busid + +From: Vineeth Vijayan + +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: +Reported-by: Cornelia Huck +Signed-off-by: Vineeth Vijayan +Reviewed-by: Cornelia Huck +Link: https://lore.kernel.org/r/20211105154451.847288-1-vneethv@linux.ibm.com +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.10/s390-cio-make-ccw_device_dma_-more-robust.patch b/queue-5.10/s390-cio-make-ccw_device_dma_-more-robust.patch new file mode 100644 index 00000000000..e0be6ea85b6 --- /dev/null +++ b/queue-5.10/s390-cio-make-ccw_device_dma_-more-robust.patch @@ -0,0 +1,81 @@ +From ad9a14517263a16af040598c7920c09ca9670a31 Mon Sep 17 00:00:00 2001 +From: Halil Pasic +Date: Wed, 8 Sep 2021 17:36:23 +0200 +Subject: s390/cio: make ccw_device_dma_* more robust + +From: Halil Pasic + +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: # v5.3 +Signed-off-by: Halil Pasic +Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and classic notifiers") +Reported-by: bfu@redhat.com +Reviewed-by: Vineeth Vijayan +Acked-by: Cornelia Huck +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-5.10/s390-tape-fix-timer-initialization-in-tape_std_assign.patch b/queue-5.10/s390-tape-fix-timer-initialization-in-tape_std_assign.patch new file mode 100644 index 00000000000..5e1a4446959 --- /dev/null +++ b/queue-5.10/s390-tape-fix-timer-initialization-in-tape_std_assign.patch @@ -0,0 +1,44 @@ +From 213fca9e23b59581c573d558aa477556f00b8198 Mon Sep 17 00:00:00 2001 +From: Sven Schnelle +Date: Tue, 2 Nov 2021 10:55:30 +0100 +Subject: s390/tape: fix timer initialization in tape_std_assign() + +From: Sven Schnelle + +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 +Reviewed-by: Vasily Gorbik +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + 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); + diff --git a/queue-5.10/series b/queue-5.10/series index 4f6bbe5b588..07c011ee90c 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -547,3 +547,26 @@ f2fs-should-use-gfp_nofs-for-directory-inodes.patch 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 diff --git a/queue-5.10/video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch b/queue-5.10/video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch new file mode 100644 index 00000000000..16922cc3ef9 --- /dev/null +++ b/queue-5.10/video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch @@ -0,0 +1,49 @@ +From 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa Mon Sep 17 00:00:00 2001 +From: Marek Vasut +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 + +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: # 5.4+ +Cc: # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling +Signed-off-by: Marek Vasut +Acked-by: Noralf Trønnes +Reviewed-by: Daniel Thompson +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } +