From: Greg Kroah-Hartman Date: Mon, 15 Nov 2021 15:06:16 +0000 (+0100) Subject: 5.14-stable patches X-Git-Tag: v5.4.160~36 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=20943740c472e6f10d1453da046374726467e8a8;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-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-fsmc-fix-use-of-sm-order.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 pm-sleep-avoid-calling-put_device-under-dpm_list_mtx.patch powerpc-32e-ignore-esr-in-instruction-storage-interrupt-handler.patch powerpc-64s-interrupt-fix-check_return_regs_valid-false-positive.patch powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch powerpc-bpf-fix-write-protecting-jit-code.patch powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch powerpc-pseries-mobility-ignore-ibm-platform-facilities-updates.patch powerpc-security-use-a-mutex-for-interrupt-exit-code-patching.patch powerpc-vas-fix-potential-null-pointer-dereference.patch remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true.patch remoteproc-fix-the-wrong-default-value-of-is_iomem.patch remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch remoteproc-imx_rproc-fix-rsc-table-name.patch 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-cpumf-cpum_cf-pmu-displays-invalid-value-after-hotplug-remove.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.14/drm-sun4i-fix-macros-in-sun8i_csc.h.patch b/queue-5.14/drm-sun4i-fix-macros-in-sun8i_csc.h.patch new file mode 100644 index 00000000000..2dbe8ded35d --- /dev/null +++ b/queue-5.14/drm-sun4i-fix-macros-in-sun8i_csc.h.patch @@ -0,0 +1,45 @@ +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(-) + +--- 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) + diff --git a/queue-5.14/mfd-dln2-add-cell-for-initializing-dln2-adc.patch b/queue-5.14/mfd-dln2-add-cell-for-initializing-dln2-adc.patch new file mode 100644 index 00000000000..2399b41a44f --- /dev/null +++ b/queue-5.14/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.14/mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch b/queue-5.14/mm-oom-do-not-trigger-out_of_memory-from-the-pf.patch new file mode 100644 index 00000000000..24815ce7b64 --- /dev/null +++ b/queue-5.14/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 +@@ -1119,19 +1119,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; +@@ -1139,8 +1135,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.14/mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch b/queue-5.14/mm-oom-pagefault_out_of_memory-don-t-force-global-oom-for-dying-tasks.patch new file mode 100644 index 00000000000..d16c9e2248f --- /dev/null +++ b/queue-5.14/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 +@@ -1136,6 +1136,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.14/mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/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.14/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.14/mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..38e6995ba8e --- /dev/null +++ b/queue-5.14/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 +@@ -239,9 +239,8 @@ static int au1550nd_exec_op(struct nand_ + + static int au1550nd_attach_chip(struct nand_chip *chip) + { +- chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; +- +- if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) ++ if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && ++ chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + return 0; +@@ -310,6 +309,13 @@ static int au1550nd_probe(struct platfor + if (pd->devwidth) + this->options |= NAND_BUSWIDTH_16; + ++ /* ++ * This driver assumes that the default ECC engine should be TYPE_SOFT. ++ * Set ->engine_type before registering the NAND devices in order to ++ * provide a driver specific default value. ++ */ ++ this->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; ++ + ret = nand_scan(this, 1); + if (ret) { + dev_err(&pdev->dev, "NAND scan failed with %d\n", ret); diff --git a/queue-5.14/mtd-rawnand-fsmc-fix-use-of-sm-order.patch b/queue-5.14/mtd-rawnand-fsmc-fix-use-of-sm-order.patch new file mode 100644 index 00000000000..14e8c40d9e4 --- /dev/null +++ b/queue-5.14/mtd-rawnand-fsmc-fix-use-of-sm-order.patch @@ -0,0 +1,42 @@ +From 9be1446ece291a1f08164bd056bed3d698681f8b Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Wed, 29 Sep 2021 00:15:00 +0200 +Subject: mtd: rawnand: fsmc: Fix use of SM ORDER + +From: Miquel Raynal + +commit 9be1446ece291a1f08164bd056bed3d698681f8b upstream. + +The introduction of the generic ECC engine API lead to a number of +changes in various drivers which broke some of them. Here is a typical +example: I expected the SM_ORDER option to be handled by the Hamming ECC +engine internals. Problem: the fsmc driver does not instantiate (yet) a +real ECC engine object so we had to use a 'bare' ECC helper instead of +the shiny rawnand functions. However, when not intializing this engine +properly and using the bare helpers, we do not get the SM ORDER feature +handled automatically. It looks like this was lost in the process so +let's ensure we use the right SM ORDER now. + +Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/fsmc_nand.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/nand/raw/fsmc_nand.c ++++ b/drivers/mtd/nand/raw/fsmc_nand.c +@@ -438,8 +438,10 @@ static int fsmc_correct_ecc1(struct nand + unsigned char *read_ecc, + unsigned char *calc_ecc) + { ++ bool sm_order = chip->ecc.options & NAND_ECC_SOFT_HAMMING_SM_ORDER; ++ + return ecc_sw_hamming_correct(buf, read_ecc, calc_ecc, +- chip->ecc.size, false); ++ chip->ecc.size, sm_order); + } + + /* Count the number of 0's in buff upto a max of max_bits */ diff --git a/queue-5.14/mtd-rawnand-gpio-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/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.14/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.14/mtd-rawnand-mpc5121-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/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.14/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.14/mtd-rawnand-orion-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/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.14/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.14/mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch new file mode 100644 index 00000000000..3c8abfe4e60 --- /dev/null +++ b/queue-5.14/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 +@@ -75,9 +75,8 @@ static int pasemi_device_ready(struct na + + static int pasemi_attach_chip(struct nand_chip *chip) + { +- chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; +- +- if (chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) ++ if (chip->ecc.engine_type == NAND_ECC_ENGINE_TYPE_SOFT && ++ chip->ecc.algo == NAND_ECC_ALGO_UNKNOWN) + chip->ecc.algo = NAND_ECC_ALGO_HAMMING; + + return 0; +@@ -154,6 +153,13 @@ static int pasemi_nand_probe(struct plat + /* Enable the following for a flash based bad block table */ + chip->bbt_options = NAND_BBT_USE_FLASH; + ++ /* ++ * This driver assumes that the default ECC engine should be TYPE_SOFT. ++ * Set ->engine_type before registering the NAND devices in order to ++ * provide a driver specific default value. ++ */ ++ chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_SOFT; ++ + /* Scan to find existence of the device */ + err = nand_scan(chip, 1); + if (err) diff --git a/queue-5.14/mtd-rawnand-plat_nand-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/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.14/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.14/mtd-rawnand-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch b/queue-5.14/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.14/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.14/pm-sleep-avoid-calling-put_device-under-dpm_list_mtx.patch b/queue-5.14/pm-sleep-avoid-calling-put_device-under-dpm_list_mtx.patch new file mode 100644 index 00000000000..34d959f80f3 --- /dev/null +++ b/queue-5.14/pm-sleep-avoid-calling-put_device-under-dpm_list_mtx.patch @@ -0,0 +1,365 @@ +From 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 4 Nov 2021 18:26:26 +0100 +Subject: PM: sleep: Avoid calling put_device() under dpm_list_mtx + +From: Rafael J. Wysocki + +commit 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 upstream. + +It is generally unsafe to call put_device() with dpm_list_mtx held, +because the given device's release routine may carry out an action +depending on that lock which then may deadlock, so modify the +system-wide suspend and resume of devices to always drop dpm_list_mtx +before calling put_device() (and adjust white space somewhat while +at it). + +For instance, this prevents the following splat from showing up in +the kernel log after a system resume in certain configurations: + +[ 3290.969514] ====================================================== +[ 3290.969517] WARNING: possible circular locking dependency detected +[ 3290.969519] 5.15.0+ #2420 Tainted: G S +[ 3290.969523] ------------------------------------------------------ +[ 3290.969525] systemd-sleep/4553 is trying to acquire lock: +[ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0 +[ 3290.969554] + but task is already holding lock: +[ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0 +[ 3290.969571] + which lock already depends on the new lock. + +[ 3290.969573] + the existing dependency chain (in reverse order) is: +[ 3290.969575] + -> #3 (dpm_list_mtx){+.+.}-{3:3}: +[ 3290.969583] __mutex_lock+0x9d/0xa30 +[ 3290.969591] device_pm_add+0x2e/0xe0 +[ 3290.969597] device_add+0x4d5/0x8f0 +[ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth] +[ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth] +[ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth] +[ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth] +[ 3290.969842] process_one_work+0x2aa/0x650 +[ 3290.969851] worker_thread+0x39/0x400 +[ 3290.969859] kthread+0x142/0x170 +[ 3290.969865] ret_from_fork+0x22/0x30 +[ 3290.969872] + -> #2 (&hdev->lock){+.+.}-{3:3}: +[ 3290.969881] __mutex_lock+0x9d/0xa30 +[ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth] +[ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth] +[ 3290.969978] process_one_work+0x2aa/0x650 +[ 3290.969985] worker_thread+0x39/0x400 +[ 3290.969993] kthread+0x142/0x170 +[ 3290.969999] ret_from_fork+0x22/0x30 +[ 3290.970004] + -> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}: +[ 3290.970013] process_one_work+0x27d/0x650 +[ 3290.970020] worker_thread+0x39/0x400 +[ 3290.970028] kthread+0x142/0x170 +[ 3290.970033] ret_from_fork+0x22/0x30 +[ 3290.970038] + -> #0 ((wq_completion)hci0#2){+.+.}-{0:0}: +[ 3290.970047] __lock_acquire+0x15cb/0x1b50 +[ 3290.970054] lock_acquire+0x26c/0x300 +[ 3290.970059] flush_workqueue+0xae/0x4a0 +[ 3290.970066] drain_workqueue+0xa1/0x130 +[ 3290.970073] destroy_workqueue+0x34/0x1f0 +[ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth] +[ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth] +[ 3290.970195] device_release+0x33/0x90 +[ 3290.970201] kobject_release+0x63/0x160 +[ 3290.970211] dpm_resume+0x164/0x3e0 +[ 3290.970215] dpm_resume_end+0xd/0x20 +[ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0 +[ 3290.970229] pm_suspend+0x26b/0x310 +[ 3290.970236] state_store+0x42/0x90 +[ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0 +[ 3290.970251] new_sync_write+0x125/0x1c0 +[ 3290.970257] vfs_write+0x360/0x3c0 +[ 3290.970263] ksys_write+0xa7/0xe0 +[ 3290.970269] do_syscall_64+0x3a/0x80 +[ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae +[ 3290.970284] + other info that might help us debug this: + +[ 3290.970285] Chain exists of: + (wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx + +[ 3290.970297] Possible unsafe locking scenario: + +[ 3290.970299] CPU0 CPU1 +[ 3290.970300] ---- ---- +[ 3290.970302] lock(dpm_list_mtx); +[ 3290.970306] lock(&hdev->lock); +[ 3290.970310] lock(dpm_list_mtx); +[ 3290.970314] lock((wq_completion)hci0#2); +[ 3290.970319] + *** DEADLOCK *** + +[ 3290.970321] 7 locks held by systemd-sleep/4553: +[ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0 +[ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0 +[ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0 +[ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90 +[ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310 +[ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80 +[ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0 +[ 3290.970428] + stack backtrace: +[ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420 +[ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019 +[ 3290.970441] Call Trace: +[ 3290.970446] dump_stack_lvl+0x44/0x57 +[ 3290.970454] check_noncircular+0x105/0x120 +[ 3290.970468] ? __lock_acquire+0x15cb/0x1b50 +[ 3290.970474] __lock_acquire+0x15cb/0x1b50 +[ 3290.970487] lock_acquire+0x26c/0x300 +[ 3290.970493] ? flush_workqueue+0x87/0x4a0 +[ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60 +[ 3290.970510] ? lockdep_init_map_type+0x58/0x240 +[ 3290.970519] flush_workqueue+0xae/0x4a0 +[ 3290.970526] ? flush_workqueue+0x87/0x4a0 +[ 3290.970544] ? drain_workqueue+0xa1/0x130 +[ 3290.970552] drain_workqueue+0xa1/0x130 +[ 3290.970561] destroy_workqueue+0x34/0x1f0 +[ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth] +[ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth] +[ 3290.970687] device_release+0x33/0x90 +[ 3290.970695] kobject_release+0x63/0x160 +[ 3290.970705] dpm_resume+0x164/0x3e0 +[ 3290.970710] ? dpm_resume_early+0x251/0x3b0 +[ 3290.970718] dpm_resume_end+0xd/0x20 +[ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0 +[ 3290.970737] pm_suspend+0x26b/0x310 +[ 3290.970746] state_store+0x42/0x90 +[ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0 +[ 3290.970764] new_sync_write+0x125/0x1c0 +[ 3290.970777] vfs_write+0x360/0x3c0 +[ 3290.970785] ksys_write+0xa7/0xe0 +[ 3290.970794] do_syscall_64+0x3a/0x80 +[ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae +[ 3290.970811] RIP: 0033:0x7f41b1328164 +[ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83 +[ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 +[ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164 +[ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004 +[ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0 +[ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004 +[ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004 + +Cc: All applicable +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/main.c | 84 +++++++++++++++++++++++++++++++--------------- + 1 file changed, 57 insertions(+), 27 deletions(-) + +--- a/drivers/base/power/main.c ++++ b/drivers/base/power/main.c +@@ -711,6 +711,7 @@ static void dpm_noirq_resume_devices(pm_ + dev = to_device(dpm_noirq_list.next); + get_device(dev); + list_move_tail(&dev->power.entry, &dpm_late_early_list); ++ + mutex_unlock(&dpm_list_mtx); + + if (!is_async(dev)) { +@@ -725,8 +726,9 @@ static void dpm_noirq_resume_devices(pm_ + } + } + +- mutex_lock(&dpm_list_mtx); + put_device(dev); ++ ++ mutex_lock(&dpm_list_mtx); + } + mutex_unlock(&dpm_list_mtx); + async_synchronize_full(); +@@ -852,6 +854,7 @@ void dpm_resume_early(pm_message_t state + dev = to_device(dpm_late_early_list.next); + get_device(dev); + list_move_tail(&dev->power.entry, &dpm_suspended_list); ++ + mutex_unlock(&dpm_list_mtx); + + if (!is_async(dev)) { +@@ -865,8 +868,10 @@ void dpm_resume_early(pm_message_t state + pm_dev_err(dev, state, " early", error); + } + } +- mutex_lock(&dpm_list_mtx); ++ + put_device(dev); ++ ++ mutex_lock(&dpm_list_mtx); + } + mutex_unlock(&dpm_list_mtx); + async_synchronize_full(); +@@ -1029,7 +1034,12 @@ void dpm_resume(pm_message_t state) + } + if (!list_empty(&dev->power.entry)) + list_move_tail(&dev->power.entry, &dpm_prepared_list); ++ ++ mutex_unlock(&dpm_list_mtx); ++ + put_device(dev); ++ ++ mutex_lock(&dpm_list_mtx); + } + mutex_unlock(&dpm_list_mtx); + async_synchronize_full(); +@@ -1107,14 +1117,16 @@ void dpm_complete(pm_message_t state) + get_device(dev); + dev->power.is_prepared = false; + list_move(&dev->power.entry, &list); ++ + mutex_unlock(&dpm_list_mtx); + + trace_device_pm_callback_start(dev, "", state.event); + device_complete(dev, state); + trace_device_pm_callback_end(dev, 0); + +- mutex_lock(&dpm_list_mtx); + put_device(dev); ++ ++ mutex_lock(&dpm_list_mtx); + } + list_splice(&list, &dpm_list); + mutex_unlock(&dpm_list_mtx); +@@ -1299,17 +1311,21 @@ static int dpm_noirq_suspend_devices(pm_ + error = device_suspend_noirq(dev); + + mutex_lock(&dpm_list_mtx); ++ + if (error) { + pm_dev_err(dev, state, " noirq", error); + dpm_save_failed_dev(dev_name(dev)); +- put_device(dev); +- break; +- } +- if (!list_empty(&dev->power.entry)) ++ } else if (!list_empty(&dev->power.entry)) { + list_move(&dev->power.entry, &dpm_noirq_list); ++ } ++ ++ mutex_unlock(&dpm_list_mtx); ++ + put_device(dev); + +- if (async_error) ++ mutex_lock(&dpm_list_mtx); ++ ++ if (error || async_error) + break; + } + mutex_unlock(&dpm_list_mtx); +@@ -1476,23 +1492,28 @@ int dpm_suspend_late(pm_message_t state) + struct device *dev = to_device(dpm_suspended_list.prev); + + get_device(dev); ++ + mutex_unlock(&dpm_list_mtx); + + error = device_suspend_late(dev); + + mutex_lock(&dpm_list_mtx); ++ + if (!list_empty(&dev->power.entry)) + list_move(&dev->power.entry, &dpm_late_early_list); + + if (error) { + pm_dev_err(dev, state, " late", error); + dpm_save_failed_dev(dev_name(dev)); +- put_device(dev); +- break; + } ++ ++ mutex_unlock(&dpm_list_mtx); ++ + put_device(dev); + +- if (async_error) ++ mutex_lock(&dpm_list_mtx); ++ ++ if (error || async_error) + break; + } + mutex_unlock(&dpm_list_mtx); +@@ -1752,21 +1773,27 @@ int dpm_suspend(pm_message_t state) + struct device *dev = to_device(dpm_prepared_list.prev); + + get_device(dev); ++ + mutex_unlock(&dpm_list_mtx); + + error = device_suspend(dev); + + mutex_lock(&dpm_list_mtx); ++ + if (error) { + pm_dev_err(dev, state, "", error); + dpm_save_failed_dev(dev_name(dev)); +- put_device(dev); +- break; +- } +- if (!list_empty(&dev->power.entry)) ++ } else if (!list_empty(&dev->power.entry)) { + list_move(&dev->power.entry, &dpm_suspended_list); ++ } ++ ++ mutex_unlock(&dpm_list_mtx); ++ + put_device(dev); +- if (async_error) ++ ++ mutex_lock(&dpm_list_mtx); ++ ++ if (error || async_error) + break; + } + mutex_unlock(&dpm_list_mtx); +@@ -1883,6 +1910,7 @@ int dpm_prepare(pm_message_t state) + struct device *dev = to_device(dpm_list.next); + + get_device(dev); ++ + mutex_unlock(&dpm_list_mtx); + + trace_device_pm_callback_start(dev, "", state.event); +@@ -1890,21 +1918,23 @@ int dpm_prepare(pm_message_t state) + trace_device_pm_callback_end(dev, error); + + mutex_lock(&dpm_list_mtx); +- if (error) { +- if (error == -EAGAIN) { +- put_device(dev); +- error = 0; +- continue; +- } ++ ++ if (!error) { ++ dev->power.is_prepared = true; ++ if (!list_empty(&dev->power.entry)) ++ list_move_tail(&dev->power.entry, &dpm_prepared_list); ++ } else if (error == -EAGAIN) { ++ error = 0; ++ } else { + dev_info(dev, "not prepared for power transition: code %d\n", + error); +- put_device(dev); +- break; + } +- dev->power.is_prepared = true; +- if (!list_empty(&dev->power.entry)) +- list_move_tail(&dev->power.entry, &dpm_prepared_list); ++ ++ mutex_unlock(&dpm_list_mtx); ++ + put_device(dev); ++ ++ mutex_lock(&dpm_list_mtx); + } + mutex_unlock(&dpm_list_mtx); + trace_suspend_resume(TPS("dpm_prepare"), state.event, false); diff --git a/queue-5.14/powerpc-32e-ignore-esr-in-instruction-storage-interrupt-handler.patch b/queue-5.14/powerpc-32e-ignore-esr-in-instruction-storage-interrupt-handler.patch new file mode 100644 index 00000000000..3b8cd9835e2 --- /dev/null +++ b/queue-5.14/powerpc-32e-ignore-esr-in-instruction-storage-interrupt-handler.patch @@ -0,0 +1,68 @@ +From 81291383ffde08b23bce75e7d6b2575ce9d3475c Mon Sep 17 00:00:00 2001 +From: Nicholas Piggin +Date: Thu, 28 Oct 2021 23:30:43 +1000 +Subject: powerpc/32e: Ignore ESR in instruction storage interrupt handler + +From: Nicholas Piggin + +commit 81291383ffde08b23bce75e7d6b2575ce9d3475c upstream. + +A e5500 machine running a 32-bit kernel sometimes hangs at boot, +seemingly going into an infinite loop of instruction storage interrupts. + +The ESR (Exception Syndrome Register) has a value of 0x800000 (store) +when this happens, which is likely set by a previous store. An +instruction TLB miss interrupt would then leave ESR unchanged, and if no +PTE exists it calls directly to the instruction storage interrupt +handler without changing ESR. + +access_error() does not cause a segfault due to a store to a read-only +vma because is_exec is true. Most subsequent fault handling does not +check for a write fault on a read-only vma, and might do strange things +like create a writeable PTE or call page_mkwrite on a read only vma or +file. It's not clear what happens here to cause the infinite faulting in +this case, a fault handler failure or low level PTE or TLB handling. + +In any case this can be fixed by having the instruction storage +interrupt zero regs->dsisr rather than storing the ESR value to it. + +Fixes: a01a3f2ddbcd ("powerpc: remove arguments from fault handler functions") +Cc: stable@vger.kernel.org # v5.12+ +Reported-by: Jacques de Laval +Signed-off-by: Nicholas Piggin +Tested-by: Jacques de Laval +Reviewed-by: Christophe Leroy +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211028133043.4159501-1-npiggin@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kernel/head_booke.h | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +--- a/arch/powerpc/kernel/head_booke.h ++++ b/arch/powerpc/kernel/head_booke.h +@@ -465,12 +465,21 @@ label: + bl do_page_fault; \ + b interrupt_return + ++/* ++ * Instruction TLB Error interrupt handlers may call InstructionStorage ++ * directly without clearing ESR, so the ESR at this point may be left over ++ * from a prior interrupt. ++ * ++ * In any case, do_page_fault for BOOK3E does not use ESR and always expects ++ * dsisr to be 0. ESR_DST from a prior store in particular would confuse fault ++ * handling. ++ */ + #define INSTRUCTION_STORAGE_EXCEPTION \ + START_EXCEPTION(InstructionStorage) \ +- NORMAL_EXCEPTION_PROLOG(0x400, INST_STORAGE); \ +- mfspr r5,SPRN_ESR; /* Grab the ESR and save it */ \ ++ NORMAL_EXCEPTION_PROLOG(0x400, INST_STORAGE); \ ++ li r5,0; /* Store 0 in regs->esr (dsisr) */ \ + stw r5,_ESR(r11); \ +- stw r12, _DEAR(r11); /* Pass SRR0 as arg2 */ \ ++ stw r12, _DEAR(r11); /* Set regs->dear (dar) to SRR0 */ \ + prepare_transfer_to_handler; \ + bl do_page_fault; \ + b interrupt_return diff --git a/queue-5.14/powerpc-64s-interrupt-fix-check_return_regs_valid-false-positive.patch b/queue-5.14/powerpc-64s-interrupt-fix-check_return_regs_valid-false-positive.patch new file mode 100644 index 00000000000..78db102bc61 --- /dev/null +++ b/queue-5.14/powerpc-64s-interrupt-fix-check_return_regs_valid-false-positive.patch @@ -0,0 +1,44 @@ +From 4a5cb51f3db4be547225a4bce7a43d41b231382b Mon Sep 17 00:00:00 2001 +From: Nicholas Piggin +Date: Tue, 26 Oct 2021 22:25:31 +1000 +Subject: powerpc/64s/interrupt: Fix check_return_regs_valid() false positive + +From: Nicholas Piggin + +commit 4a5cb51f3db4be547225a4bce7a43d41b231382b upstream. + +The check_return_regs_valid() can cause a false positive if the return +regs are marked as norestart and they are an HSRR type interrupt, +because the low bit in the bottom of regs->trap causes interrupt type +matching to fail. + +This can occcur for example on bare metal with a HV privileged doorbell +interrupt that causes a signal, but do_signal returns early because +get_signal() fails, and takes the "No signal to deliver" path. In this +case no signal was delivered so the return location is not changed so +return SRRs are not invalidated, yet set_trap_norestart is called, which +messes up the match. Building go-1.16.6 is known to reproduce this. + +Fix it by using the TRAP() accessor which masks out the low bit. + +Fixes: 6eaaf9de3599 ("powerpc/64s/interrupt: Check and fix srr_valid without crashing") +Cc: stable@vger.kernel.org # v5.14+ +Signed-off-by: Nicholas Piggin +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211026122531.3599918-1-npiggin@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kernel/interrupt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/interrupt.c ++++ b/arch/powerpc/kernel/interrupt.c +@@ -268,7 +268,7 @@ static void check_return_regs_valid(stru + if (trap_is_scv(regs)) + return; + +- trap = regs->trap; ++ trap = TRAP(regs); + // EE in HV mode sets HSRRs like 0xea0 + if (cpu_has_feature(CPU_FTR_HVMODE) && trap == INTERRUPT_EXTERNAL) + trap = 0xea0; diff --git a/queue-5.14/powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch b/queue-5.14/powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch new file mode 100644 index 00000000000..a5e418350db --- /dev/null +++ b/queue-5.14/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.14/powerpc-bpf-fix-write-protecting-jit-code.patch b/queue-5.14/powerpc-bpf-fix-write-protecting-jit-code.patch new file mode 100644 index 00000000000..32d414ef1d3 --- /dev/null +++ b/queue-5.14/powerpc-bpf-fix-write-protecting-jit-code.patch @@ -0,0 +1,49 @@ +From 44a8214de96bafb5210e43bfa2c97c19bf75af3d Mon Sep 17 00:00:00 2001 +From: Hari Bathini +Date: Mon, 25 Oct 2021 11:26:49 +0530 +Subject: powerpc/bpf: Fix write protecting JIT code + +From: Hari Bathini + +commit 44a8214de96bafb5210e43bfa2c97c19bf75af3d upstream. + +Running program with bpf-to-bpf function calls results in data access +exception (0x300) with the below call trace: + + bpf_int_jit_compile+0x238/0x750 (unreliable) + bpf_check+0x2008/0x2710 + bpf_prog_load+0xb00/0x13a0 + __sys_bpf+0x6f4/0x27c0 + sys_bpf+0x2c/0x40 + system_call_exception+0x164/0x330 + system_call_vectored_common+0xe8/0x278 + +as bpf_int_jit_compile() tries writing to write protected JIT code +location during the extra pass. + +Fix it by holding off write protection of JIT code until the extra +pass, where branch target addresses fixup happens. + +Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code") +Cc: stable@vger.kernel.org # v5.14+ +Signed-off-by: Hari Bathini +Reviewed-by: Naveen N. Rao +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211025055649.114728-1-hbathini@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/net/bpf_jit_comp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/net/bpf_jit_comp.c ++++ b/arch/powerpc/net/bpf_jit_comp.c +@@ -241,8 +241,8 @@ skip_codegen_passes: + fp->jited_len = alloclen; + + bpf_flush_icache(bpf_hdr, (u8 *)bpf_hdr + (bpf_hdr->pages * PAGE_SIZE)); +- bpf_jit_binary_lock_ro(bpf_hdr); + if (!fp->is_func || extra_pass) { ++ bpf_jit_binary_lock_ro(bpf_hdr); + bpf_prog_fill_jited_linfo(fp, addrs); + out_addrs: + kfree(addrs); diff --git a/queue-5.14/powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch b/queue-5.14/powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch new file mode 100644 index 00000000000..931f74d14dd --- /dev/null +++ b/queue-5.14/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 +@@ -369,6 +369,12 @@ static struct notifier_block opal_prd_ev + .priority = 0, + }; + ++static struct notifier_block opal_prd_event_nb2 = { ++ .notifier_call = opal_prd_msg_notifier, ++ .next = NULL, ++ .priority = 0, ++}; ++ + static int opal_prd_probe(struct platform_device *pdev) + { + int rc; +@@ -390,9 +396,10 @@ static int opal_prd_probe(struct platfor + return rc; + } + +- rc = opal_message_notifier_register(OPAL_MSG_PRD2, &opal_prd_event_nb); ++ rc = opal_message_notifier_register(OPAL_MSG_PRD2, &opal_prd_event_nb2); + if (rc) { + pr_err("Couldn't register PRD2 event notifier\n"); ++ opal_message_notifier_unregister(OPAL_MSG_PRD, &opal_prd_event_nb); + return rc; + } + +@@ -401,6 +408,8 @@ static int opal_prd_probe(struct platfor + pr_err("failed to register miscdev\n"); + opal_message_notifier_unregister(OPAL_MSG_PRD, + &opal_prd_event_nb); ++ opal_message_notifier_unregister(OPAL_MSG_PRD2, ++ &opal_prd_event_nb2); + return rc; + } + +@@ -411,6 +420,7 @@ static int opal_prd_remove(struct platfo + { + misc_deregister(&opal_prd_dev); + opal_message_notifier_unregister(OPAL_MSG_PRD, &opal_prd_event_nb); ++ opal_message_notifier_unregister(OPAL_MSG_PRD2, &opal_prd_event_nb2); + return 0; + } + diff --git a/queue-5.14/powerpc-pseries-mobility-ignore-ibm-platform-facilities-updates.patch b/queue-5.14/powerpc-pseries-mobility-ignore-ibm-platform-facilities-updates.patch new file mode 100644 index 00000000000..3c9439c13cc --- /dev/null +++ b/queue-5.14/powerpc-pseries-mobility-ignore-ibm-platform-facilities-updates.patch @@ -0,0 +1,176 @@ +From 319fa1a52e438a6e028329187783a25ad498c4e6 Mon Sep 17 00:00:00 2001 +From: Nathan Lynch +Date: Wed, 20 Oct 2021 14:47:03 -0500 +Subject: powerpc/pseries/mobility: ignore ibm, platform-facilities updates +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Nathan Lynch + +commit 319fa1a52e438a6e028329187783a25ad498c4e6 upstream. + +On VMs with NX encryption, compression, and/or RNG offload, these +capabilities are described by nodes in the ibm,platform-facilities device +tree hierarchy: + + $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/ + /sys/firmware/devicetree/base/ibm,platform-facilities/ + ├── ibm,compression-v1 + ├── ibm,random-v1 + └── ibm,sym-encryption-v1 + + 3 directories + +The acceleration functions that these nodes describe are not disrupted by +live migration, not even temporarily. + +But the post-migration ibm,update-nodes sequence firmware always sends +"delete" messages for this hierarchy, followed by an "add" directive to +reconstruct it via ibm,configure-connector (log with debugging statements +enabled in mobility.c): + + mobility: removing node /ibm,platform-facilities/ibm,random-v1:4294967285 + mobility: removing node /ibm,platform-facilities/ibm,compression-v1:4294967284 + mobility: removing node /ibm,platform-facilities/ibm,sym-encryption-v1:4294967283 + mobility: removing node /ibm,platform-facilities:4294967286 + ... + mobility: added node /ibm,platform-facilities:4294967286 + +Note we receive a single "add" message for the entire hierarchy, and what +we receive from the ibm,configure-connector sequence is the top-level +platform-facilities node along with its three children. The debug message +simply reports the parent node and not the whole subtree. + +Also, significantly, the nodes added are almost completely equivalent to +the ones removed; even phandles are unchanged. ibm,shared-interrupt-pool in +the leaf nodes is the only property I've observed to differ, and Linux does +not use that. So in practice, the sum of update messages Linux receives for +this hierarchy is equivalent to minor property updates. + +We succeed in removing the original hierarchy from the device tree. But the +vio bus code is ignorant of this, and does not unbind or relinquish its +references. The leaf nodes, still reachable through sysfs, of course still +refer to the now-freed ibm,platform-facilities parent node, which makes +use-after-free possible: + + refcount_t: addition on 0; use-after-free. + WARNING: CPU: 3 PID: 1706 at lib/refcount.c:25 refcount_warn_saturate+0x164/0x1f0 + refcount_warn_saturate+0x160/0x1f0 (unreliable) + kobject_get+0xf0/0x100 + of_node_get+0x30/0x50 + of_get_parent+0x50/0xb0 + of_fwnode_get_parent+0x54/0x90 + fwnode_count_parents+0x50/0x150 + fwnode_full_name_string+0x30/0x110 + device_node_string+0x49c/0x790 + vsnprintf+0x1c0/0x4c0 + sprintf+0x44/0x60 + devspec_show+0x34/0x50 + dev_attr_show+0x40/0xa0 + sysfs_kf_seq_show+0xbc/0x200 + kernfs_seq_show+0x44/0x60 + seq_read_iter+0x2a4/0x740 + kernfs_fop_read_iter+0x254/0x2e0 + new_sync_read+0x120/0x190 + vfs_read+0x1d0/0x240 + +Moreover, the "new" replacement subtree is not correctly added to the +device tree, resulting in ibm,platform-facilities parent node without the +appropriate leaf nodes, and broken symlinks in the sysfs device hierarchy: + + $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/ + /sys/firmware/devicetree/base/ibm,platform-facilities/ + + 0 directories + + $ cd /sys/devices/vio ; find . -xtype l -exec file {} + + ./ibm,sym-encryption-v1/of_node: broken symbolic link to + ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,sym-encryption-v1 + ./ibm,random-v1/of_node: broken symbolic link to + ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,random-v1 + ./ibm,compression-v1/of_node: broken symbolic link to + ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,compression-v1 + +This is because add_dt_node() -> dlpar_attach_node() attaches only the +parent node returned from configure-connector, ignoring any children. This +should be corrected for the general case, but fixing that won't help with +the stale OF node references, which is the more urgent problem. + +One way to address that would be to make the drivers respond to node +removal notifications, so that node references can be dropped +appropriately. But this would likely force the drivers to disrupt active +clients for no useful purpose: equivalent nodes are immediately re-added. +And recall that the acceleration capabilities described by the nodes remain +available throughout the whole process. + +The solution I believe to be robust for this situation is to convert +remove+add of a node with an unchanged phandle to an update of the node's +properties in the Linux device tree structure. That would involve changing +and adding a fair amount of code, and may take several iterations to land. + +Until that can be realized we have a confirmed use-after-free and the +possibility of memory corruption. So add a limited workaround that +discriminates on the node type, ignoring adds and removes. This should be +amenable to backporting in the meantime. + +Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel") +Cc: stable@vger.kernel.org +Signed-off-by: Nathan Lynch +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211020194703.2613093-1-nathanl@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/platforms/pseries/mobility.c | 34 ++++++++++++++++++++++++++++++ + 1 file changed, 34 insertions(+) + +--- a/arch/powerpc/platforms/pseries/mobility.c ++++ b/arch/powerpc/platforms/pseries/mobility.c +@@ -63,6 +63,27 @@ static int mobility_rtas_call(int token, + + static int delete_dt_node(struct device_node *dn) + { ++ struct device_node *pdn; ++ bool is_platfac; ++ ++ pdn = of_get_parent(dn); ++ is_platfac = of_node_is_type(dn, "ibm,platform-facilities") || ++ of_node_is_type(pdn, "ibm,platform-facilities"); ++ of_node_put(pdn); ++ ++ /* ++ * The drivers that bind to nodes in the platform-facilities ++ * hierarchy don't support node removal, and the removal directive ++ * from firmware is always followed by an add of an equivalent ++ * node. The capability (e.g. RNG, encryption, compression) ++ * represented by the node is never interrupted by the migration. ++ * So ignore changes to this part of the tree. ++ */ ++ if (is_platfac) { ++ pr_notice("ignoring remove operation for %pOFfp\n", dn); ++ return 0; ++ } ++ + pr_debug("removing node %pOFfp\n", dn); + dlpar_detach_node(dn); + return 0; +@@ -222,6 +243,19 @@ static int add_dt_node(struct device_nod + if (!dn) + return -ENOENT; + ++ /* ++ * Since delete_dt_node() ignores this node type, this is the ++ * necessary counterpart. We also know that a platform-facilities ++ * node returned from dlpar_configure_connector() has children ++ * attached, and dlpar_attach_node() only adds the parent, leaking ++ * the children. So ignore these on the add side for now. ++ */ ++ if (of_node_is_type(dn, "ibm,platform-facilities")) { ++ pr_notice("ignoring add operation for %pOF\n", dn); ++ dlpar_free_cc_nodes(dn); ++ return 0; ++ } ++ + rc = dlpar_attach_node(dn, parent_dn); + if (rc) + dlpar_free_cc_nodes(dn); diff --git a/queue-5.14/powerpc-security-use-a-mutex-for-interrupt-exit-code-patching.patch b/queue-5.14/powerpc-security-use-a-mutex-for-interrupt-exit-code-patching.patch new file mode 100644 index 00000000000..9e00ed13473 --- /dev/null +++ b/queue-5.14/powerpc-security-use-a-mutex-for-interrupt-exit-code-patching.patch @@ -0,0 +1,78 @@ +From 3c12b4df8d5e026345a19886ae375b3ebc33c0b6 Mon Sep 17 00:00:00 2001 +From: Russell Currey +Date: Wed, 27 Oct 2021 17:24:10 +1000 +Subject: powerpc/security: Use a mutex for interrupt exit code patching + +From: Russell Currey + +commit 3c12b4df8d5e026345a19886ae375b3ebc33c0b6 upstream. + +The mitigation-patching.sh script in the powerpc selftests toggles +all mitigations on and off simultaneously, revealing that rfi_flush +and stf_barrier cannot safely operate at the same time due to races +in updating the static key. + +On some systems, the static key code throws a warning and the kernel +remains functional. On others, the kernel will hang or crash. + +Fix this by slapping on a mutex. + +Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt") +Cc: stable@vger.kernel.org # v5.14+ +Signed-off-by: Russell Currey +Acked-by: Nicholas Piggin +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211027072410.40950-1-ruscur@russell.cc +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/lib/feature-fixups.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/powerpc/lib/feature-fixups.c ++++ b/arch/powerpc/lib/feature-fixups.c +@@ -228,6 +228,7 @@ static void do_stf_exit_barrier_fixups(e + + static bool stf_exit_reentrant = false; + static bool rfi_exit_reentrant = false; ++static DEFINE_MUTEX(exit_flush_lock); + + static int __do_stf_barrier_fixups(void *data) + { +@@ -253,6 +254,9 @@ void do_stf_barrier_fixups(enum stf_barr + * low level interrupt exit code before patching. After the patching, + * if allowed, then flip the branch to allow fast exits. + */ ++ ++ // Prevent static key update races with do_rfi_flush_fixups() ++ mutex_lock(&exit_flush_lock); + static_branch_enable(&interrupt_exit_not_reentrant); + + stop_machine(__do_stf_barrier_fixups, &types, NULL); +@@ -264,6 +268,8 @@ void do_stf_barrier_fixups(enum stf_barr + + if (stf_exit_reentrant && rfi_exit_reentrant) + static_branch_disable(&interrupt_exit_not_reentrant); ++ ++ mutex_unlock(&exit_flush_lock); + } + + void do_uaccess_flush_fixups(enum l1d_flush_type types) +@@ -486,6 +492,9 @@ void do_rfi_flush_fixups(enum l1d_flush_ + * without stop_machine, so this could be achieved with a broadcast + * IPI instead, but this matches the stf sequence. + */ ++ ++ // Prevent static key update races with do_stf_barrier_fixups() ++ mutex_lock(&exit_flush_lock); + static_branch_enable(&interrupt_exit_not_reentrant); + + stop_machine(__do_rfi_flush_fixups, &types, NULL); +@@ -497,6 +506,8 @@ void do_rfi_flush_fixups(enum l1d_flush_ + + if (stf_exit_reentrant && rfi_exit_reentrant) + static_branch_disable(&interrupt_exit_not_reentrant); ++ ++ mutex_unlock(&exit_flush_lock); + } + + void do_barrier_nospec_fixups_range(bool enable, void *fixup_start, void *fixup_end) diff --git a/queue-5.14/powerpc-vas-fix-potential-null-pointer-dereference.patch b/queue-5.14/powerpc-vas-fix-potential-null-pointer-dereference.patch new file mode 100644 index 00000000000..79e400a057e --- /dev/null +++ b/queue-5.14/powerpc-vas-fix-potential-null-pointer-dereference.patch @@ -0,0 +1,50 @@ +From 61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Fri, 15 Oct 2021 00:03:45 -0500 +Subject: powerpc/vas: Fix potential NULL pointer dereference + +From: Gustavo A. R. Silva + +commit 61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36 upstream. + +(!ptr && !ptr->foo) strikes again. :) + +The expression (!ptr && !ptr->foo) is bogus and in case ptr is NULL, +it leads to a NULL pointer dereference: ptr->foo. + +Fix this by converting && to || + +This issue was detected with the help of Coccinelle, and audited and +fixed manually. + +Fixes: 1a0d0d5ed5e3 ("powerpc/vas: Add platform specific user window operations") +Cc: stable@vger.kernel.org +Signed-off-by: Gustavo A. R. Silva +Reviewed-by: Tyrel Datwyler +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20211015050345.GA1161918@embeddedor +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/platforms/book3s/vas-api.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/platforms/book3s/vas-api.c ++++ b/arch/powerpc/platforms/book3s/vas-api.c +@@ -303,7 +303,7 @@ static int coproc_ioc_tx_win_open(struct + return -EINVAL; + } + +- if (!cp_inst->coproc->vops && !cp_inst->coproc->vops->open_win) { ++ if (!cp_inst->coproc->vops || !cp_inst->coproc->vops->open_win) { + pr_err("VAS API is not registered\n"); + return -EACCES; + } +@@ -373,7 +373,7 @@ static int coproc_mmap(struct file *fp, + return -EINVAL; + } + +- if (!cp_inst->coproc->vops && !cp_inst->coproc->vops->paste_addr) { ++ if (!cp_inst->coproc->vops || !cp_inst->coproc->vops->paste_addr) { + pr_err("%s(): VAS API is not registered\n", __func__); + return -EACCES; + } diff --git a/queue-5.14/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true.patch b/queue-5.14/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true.patch new file mode 100644 index 00000000000..d7b7ae6f314 --- /dev/null +++ b/queue-5.14/remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true.patch @@ -0,0 +1,37 @@ +From 24acbd9dc934f5d9418a736c532d3970a272063e Mon Sep 17 00:00:00 2001 +From: Peng Fan +Date: Fri, 10 Sep 2021 17:06:16 +0800 +Subject: remoteproc: elf_loader: Fix loading segment when is_iomem true + +From: Peng Fan + +commit 24acbd9dc934f5d9418a736c532d3970a272063e upstream. + +It seems luckliy work on i.MX platform, but it is wrong. +Need use memcpy_toio, not memcpy_fromio. + +Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va") +Tested-by: Dong Aisheng (i.MX8MQ) +Reported-by: kernel test robot +Reported-by: Dong Aisheng +Signed-off-by: Peng Fan +Cc: stable +Link: https://lore.kernel.org/r/20210910090621.3073540-2-peng.fan@oss.nxp.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/remoteproc/remoteproc_elf_loader.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/remoteproc/remoteproc_elf_loader.c ++++ b/drivers/remoteproc/remoteproc_elf_loader.c +@@ -220,7 +220,7 @@ int rproc_elf_load_segments(struct rproc + /* put the segment where the remote processor expects it */ + if (filesz) { + if (is_iomem) +- memcpy_fromio(ptr, (void __iomem *)(elf_data + offset), filesz); ++ memcpy_toio((void __iomem *)ptr, elf_data + offset, filesz); + else + memcpy(ptr, elf_data + offset, filesz); + } diff --git a/queue-5.14/remoteproc-fix-the-wrong-default-value-of-is_iomem.patch b/queue-5.14/remoteproc-fix-the-wrong-default-value-of-is_iomem.patch new file mode 100644 index 00000000000..0cb6f842dd6 --- /dev/null +++ b/queue-5.14/remoteproc-fix-the-wrong-default-value-of-is_iomem.patch @@ -0,0 +1,53 @@ +From 970675f61bf5761d7e5326f6e4df995ecdba5e11 Mon Sep 17 00:00:00 2001 +From: Dong Aisheng +Date: Fri, 10 Sep 2021 17:06:17 +0800 +Subject: remoteproc: Fix the wrong default value of is_iomem + +From: Dong Aisheng + +commit 970675f61bf5761d7e5326f6e4df995ecdba5e11 upstream. + +Currently the is_iomem is a random value in the stack which may +be default to true even on those platforms that not use iomem to +store firmware. + +Cc: Bjorn Andersson +Cc: Mathieu Poirier +Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va") +Reviewed-and-tested-by: Peng Fan +Signed-off-by: Dong Aisheng +Signed-off-by: Peng Fan +Cc: stable +Link: https://lore.kernel.org/r/20210910090621.3073540-3-peng.fan@oss.nxp.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/remoteproc/remoteproc_coredump.c | 2 +- + drivers/remoteproc/remoteproc_elf_loader.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/remoteproc/remoteproc_coredump.c ++++ b/drivers/remoteproc/remoteproc_coredump.c +@@ -152,8 +152,8 @@ static void rproc_copy_segment(struct rp + struct rproc_dump_segment *segment, + size_t offset, size_t size) + { ++ bool is_iomem = false; + void *ptr; +- bool is_iomem; + + if (segment->dump) { + segment->dump(rproc, segment, dest, offset, size); +--- a/drivers/remoteproc/remoteproc_elf_loader.c ++++ b/drivers/remoteproc/remoteproc_elf_loader.c +@@ -178,8 +178,8 @@ int rproc_elf_load_segments(struct rproc + u64 filesz = elf_phdr_get_p_filesz(class, phdr); + u64 offset = elf_phdr_get_p_offset(class, phdr); + u32 type = elf_phdr_get_p_type(class, phdr); ++ bool is_iomem = false; + void *ptr; +- bool is_iomem; + + if (type != PT_LOAD) + continue; diff --git a/queue-5.14/remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch b/queue-5.14/remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch new file mode 100644 index 00000000000..1b3560d476e --- /dev/null +++ b/queue-5.14/remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch @@ -0,0 +1,38 @@ +From afe670e23af91d8a74a8d7049f6e0984bbf6ea11 Mon Sep 17 00:00:00 2001 +From: Dong Aisheng +Date: Fri, 10 Sep 2021 17:06:19 +0800 +Subject: remoteproc: imx_rproc: Fix ignoring mapping vdev regions + +From: Dong Aisheng + +commit afe670e23af91d8a74a8d7049f6e0984bbf6ea11 upstream. + +vdev regions are typically named vdev0buffer, vdev0ring0, vdev0ring1 and +etc. Change to strncmp to cover them all. + +Fixes: 8f2d8961640f ("remoteproc: imx_rproc: ignore mapping vdev regions") +Reviewed-and-tested-by: Peng Fan +Signed-off-by: Dong Aisheng +Signed-off-by: Peng Fan +Cc: stable +Link: https://lore.kernel.org/r/20210910090621.3073540-5-peng.fan@oss.nxp.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/remoteproc/imx_rproc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/remoteproc/imx_rproc.c ++++ b/drivers/remoteproc/imx_rproc.c +@@ -582,8 +582,8 @@ static int imx_rproc_addr_init(struct im + struct resource res; + + node = of_parse_phandle(np, "memory-region", a); +- /* Not map vdev region */ +- if (!strcmp(node->name, "vdev")) ++ /* Not map vdevbuffer, vdevring region */ ++ if (!strncmp(node->name, "vdev", strlen("vdev"))) + continue; + err = of_address_to_resource(node, 0, &res); + if (err) { diff --git a/queue-5.14/remoteproc-imx_rproc-fix-rsc-table-name.patch b/queue-5.14/remoteproc-imx_rproc-fix-rsc-table-name.patch new file mode 100644 index 00000000000..94c442ab63d --- /dev/null +++ b/queue-5.14/remoteproc-imx_rproc-fix-rsc-table-name.patch @@ -0,0 +1,39 @@ +From e90547d59d4e29e269e22aa6ce590ed0b41207d2 Mon Sep 17 00:00:00 2001 +From: Dong Aisheng +Date: Fri, 10 Sep 2021 17:06:20 +0800 +Subject: remoteproc: imx_rproc: Fix rsc-table name + +From: Dong Aisheng + +commit e90547d59d4e29e269e22aa6ce590ed0b41207d2 upstream. + +Usually the dash '-' is preferred in node name. +So far, not dts in upstream kernel, so we just update node name +in driver. + +Cc: Bjorn Andersson +Cc: Mathieu Poirier +Fixes: 5e4c1243071d ("remoteproc: imx_rproc: support remote cores booted before Linux Kernel") +Reviewed-and-tested-by: Peng Fan +Signed-off-by: Dong Aisheng +Signed-off-by: Peng Fan +Cc: stable +Link: https://lore.kernel.org/r/20210910090621.3073540-6-peng.fan@oss.nxp.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/remoteproc/imx_rproc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/remoteproc/imx_rproc.c ++++ b/drivers/remoteproc/imx_rproc.c +@@ -604,7 +604,7 @@ static int imx_rproc_addr_init(struct im + } + priv->mem[b].sys_addr = res.start; + priv->mem[b].size = resource_size(&res); +- if (!strcmp(node->name, "rsc_table")) ++ if (!strcmp(node->name, "rsc-table")) + priv->rsc_table = priv->mem[b].cpu_addr; + b++; + } diff --git a/queue-5.14/s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch b/queue-5.14/s390-ap-fix-hanging-ioctl-caused-by-orphaned-replies.patch new file mode 100644 index 00000000000..f9575b3c370 --- /dev/null +++ b/queue-5.14/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 +@@ -157,6 +157,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.14/s390-cio-check-the-subchannel-validity-for-dev_busid.patch b/queue-5.14/s390-cio-check-the-subchannel-validity-for-dev_busid.patch new file mode 100644 index 00000000000..1bfa992dcd7 --- /dev/null +++ b/queue-5.14/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 +@@ -437,8 +437,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.14/s390-cio-make-ccw_device_dma_-more-robust.patch b/queue-5.14/s390-cio-make-ccw_device_dma_-more-robust.patch new file mode 100644 index 00000000000..e0be6ea85b6 --- /dev/null +++ b/queue-5.14/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.14/s390-cpumf-cpum_cf-pmu-displays-invalid-value-after-hotplug-remove.patch b/queue-5.14/s390-cpumf-cpum_cf-pmu-displays-invalid-value-after-hotplug-remove.patch new file mode 100644 index 00000000000..54b149210d1 --- /dev/null +++ b/queue-5.14/s390-cpumf-cpum_cf-pmu-displays-invalid-value-after-hotplug-remove.patch @@ -0,0 +1,56 @@ +From 9d48c7afedf91a02d03295837ec76b2fb5e7d3fe Mon Sep 17 00:00:00 2001 +From: Thomas Richter +Date: Wed, 3 Nov 2021 13:13:04 +0100 +Subject: s390/cpumf: cpum_cf PMU displays invalid value after hotplug remove + +From: Thomas Richter + +commit 9d48c7afedf91a02d03295837ec76b2fb5e7d3fe upstream. + +When a CPU is hotplugged while the perf stat -e cycles command is +running, a wrong (very large) value is displayed immediately after the +CPU removal: + + Check the values, shouldn't be too high as in + time counts unit events + 1.001101919 29261846 cycles + 2.002454499 17523405 cycles + 3.003659292 24361161 cycles + 4.004816983 18446744073638406144 cycles + 5.005671647 cycles + ... + +The CPU hotplug off took place after 3 seconds. +The issue is the read of the event count value after 4 seconds when +the CPU is not available and the read of the counter returns an +error. This is treated as a counter value of zero. This results +in a very large value (0 - previous_value). + +Fix this by detecting the hotplugged off CPU and report 0 instead +of a very large number. + +Cc: stable@vger.kernel.org +Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") +Reported-by: Sumanth Korikkar +Signed-off-by: Thomas Richter +Reviewed-by: Sumanth Korikkar +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/kernel/perf_cpum_cf.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/s390/kernel/perf_cpum_cf.c ++++ b/arch/s390/kernel/perf_cpum_cf.c +@@ -679,8 +679,10 @@ static void cpumf_pmu_stop(struct perf_e + false); + if (cfdiag_diffctr(cpuhw, event->hw.config_base)) + cfdiag_push_sample(event, cpuhw); +- } else ++ } else if (cpuhw->flags & PMU_F_RESERVED) { ++ /* Only update when PMU not hotplugged off */ + hw_perf_event_update(event); ++ } + hwc->state |= PERF_HES_UPTODATE; + } + } diff --git a/queue-5.14/s390-tape-fix-timer-initialization-in-tape_std_assign.patch b/queue-5.14/s390-tape-fix-timer-initialization-in-tape_std_assign.patch new file mode 100644 index 00000000000..5e1a4446959 --- /dev/null +++ b/queue-5.14/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.14/series b/queue-5.14/series index a4b2eefa266..e325e62665f 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -811,3 +811,35 @@ memcg-prohibit-unconditional-exceeding-the-limit-of-dying-tasks.patch io-wq-ensure-that-hash-wait-lock-is-irq-disabling.patch io-wq-fix-queue-stalling-race.patch io-wq-serialize-hash-clear-with-wakeup.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 +pm-sleep-avoid-calling-put_device-under-dpm_list_mtx.patch +s390-cpumf-cpum_cf-pmu-displays-invalid-value-after-hotplug-remove.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 +remoteproc-elf_loader-fix-loading-segment-when-is_iomem-true.patch +remoteproc-fix-the-wrong-default-value-of-is_iomem.patch +remoteproc-imx_rproc-fix-ignoring-mapping-vdev-regions.patch +remoteproc-imx_rproc-fix-rsc-table-name.patch +mtd-rawnand-fsmc-fix-use-of-sm-order.patch +mtd-rawnand-ams-delta-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-xway-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-mpc5121-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-gpio-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-pasemi-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-orion-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-plat_nand-keep-the-driver-compatible-with-on-die-ecc-engines.patch +mtd-rawnand-au1550nd-keep-the-driver-compatible-with-on-die-ecc-engines.patch +powerpc-vas-fix-potential-null-pointer-dereference.patch +powerpc-bpf-fix-write-protecting-jit-code.patch +powerpc-32e-ignore-esr-in-instruction-storage-interrupt-handler.patch +powerpc-powernv-prd-unregister-opal_msg_prd2-notifier-during-module-unload.patch +powerpc-security-use-a-mutex-for-interrupt-exit-code-patching.patch +powerpc-64s-interrupt-fix-check_return_regs_valid-false-positive.patch +powerpc-pseries-mobility-ignore-ibm-platform-facilities-updates.patch +powerpc-85xx-fix-timebase-sync-issue-when-config_hotplug_cpu-n.patch +drm-sun4i-fix-macros-in-sun8i_csc.h.patch diff --git a/queue-5.14/video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch b/queue-5.14/video-backlight-drop-maximum-brightness-override-for-brightness-zero.patch new file mode 100644 index 00000000000..16922cc3ef9 --- /dev/null +++ b/queue-5.14/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; + } + } +