From df6edd0d582bdacc3eee74ba94a6aaf39a0bc97a Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 27 Sep 2021 13:03:01 +0200 Subject: [PATCH] 5.14-stable patches added patches: edac-dmc520-assign-the-proper-type-to-dimm-edac_mode.patch edac-synopsys-fix-wrong-value-type-assignment-for-edac_mode.patch irqchip-armada-370-xp-fix-ack-eoi-breakage.patch thermal-drivers-int340x-do-not-set-a-wrong-tcc-offset-on-resume.patch x86-setup-call-early_reserve_memory-earlier.patch --- ...gn-the-proper-type-to-dimm-edac_mode.patch | 32 ++++++++ ...-value-type-assignment-for-edac_mode.patch | 39 ++++++++++ ...p-armada-370-xp-fix-ack-eoi-breakage.patch | 49 ++++++++++++ queue-5.14/series | 5 ++ ...not-set-a-wrong-tcc-offset-on-resume.patch | 68 +++++++++++++++++ ...up-call-early_reserve_memory-earlier.patch | 76 +++++++++++++++++++ 6 files changed, 269 insertions(+) create mode 100644 queue-5.14/edac-dmc520-assign-the-proper-type-to-dimm-edac_mode.patch create mode 100644 queue-5.14/edac-synopsys-fix-wrong-value-type-assignment-for-edac_mode.patch create mode 100644 queue-5.14/irqchip-armada-370-xp-fix-ack-eoi-breakage.patch create mode 100644 queue-5.14/thermal-drivers-int340x-do-not-set-a-wrong-tcc-offset-on-resume.patch create mode 100644 queue-5.14/x86-setup-call-early_reserve_memory-earlier.patch diff --git a/queue-5.14/edac-dmc520-assign-the-proper-type-to-dimm-edac_mode.patch b/queue-5.14/edac-dmc520-assign-the-proper-type-to-dimm-edac_mode.patch new file mode 100644 index 00000000000..09d76fbaeeb --- /dev/null +++ b/queue-5.14/edac-dmc520-assign-the-proper-type-to-dimm-edac_mode.patch @@ -0,0 +1,32 @@ +From 54607282fae6148641a08d81a6e0953b541249c7 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Thu, 16 Sep 2021 10:44:06 +0200 +Subject: EDAC/dmc520: Assign the proper type to dimm->edac_mode + +From: Borislav Petkov + +commit 54607282fae6148641a08d81a6e0953b541249c7 upstream. + +dimm->edac_mode contains values of type enum edac_type - not the +corresponding capability flags. Fix that. + +Fixes: 1088750d7839 ("EDAC: Add EDAC driver for DMC520") +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210916085258.7544-1-bp@alien8.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/edac/dmc520_edac.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/edac/dmc520_edac.c ++++ b/drivers/edac/dmc520_edac.c +@@ -464,7 +464,7 @@ static void dmc520_init_csrow(struct mem + dimm->grain = pvt->mem_width_in_bytes; + dimm->dtype = dt; + dimm->mtype = mt; +- dimm->edac_mode = EDAC_FLAG_SECDED; ++ dimm->edac_mode = EDAC_SECDED; + dimm->nr_pages = pages_per_rank / csi->nr_channels; + } + } diff --git a/queue-5.14/edac-synopsys-fix-wrong-value-type-assignment-for-edac_mode.patch b/queue-5.14/edac-synopsys-fix-wrong-value-type-assignment-for-edac_mode.patch new file mode 100644 index 00000000000..df1dbe8246e --- /dev/null +++ b/queue-5.14/edac-synopsys-fix-wrong-value-type-assignment-for-edac_mode.patch @@ -0,0 +1,39 @@ +From 5297cfa6bdf93e3889f78f9b482e2a595a376083 Mon Sep 17 00:00:00 2001 +From: Sai Krishna Potthuri +Date: Wed, 18 Aug 2021 12:53:14 +0530 +Subject: EDAC/synopsys: Fix wrong value type assignment for edac_mode + +From: Sai Krishna Potthuri + +commit 5297cfa6bdf93e3889f78f9b482e2a595a376083 upstream. + +dimm->edac_mode contains values of type enum edac_type - not the +corresponding capability flags. Fix that. + +Issue caught by Coverity check "enumerated type mixed with another +type." + + [ bp: Rewrite commit message, add tags. ] + +Fixes: ae9b56e3996d ("EDAC, synps: Add EDAC support for zynq ddr ecc controller") +Signed-off-by: Sai Krishna Potthuri +Signed-off-by: Shubhrajyoti Datta +Signed-off-by: Borislav Petkov +Cc: +Link: https://lkml.kernel.org/r/20210818072315.15149-1-shubhrajyoti.datta@xilinx.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/edac/synopsys_edac.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/edac/synopsys_edac.c ++++ b/drivers/edac/synopsys_edac.c +@@ -782,7 +782,7 @@ static void init_csrows(struct mem_ctl_i + + for (j = 0; j < csi->nr_channels; j++) { + dimm = csi->channels[j]->dimm; +- dimm->edac_mode = EDAC_FLAG_SECDED; ++ dimm->edac_mode = EDAC_SECDED; + dimm->mtype = p_data->get_mtype(priv->baseaddr); + dimm->nr_pages = (size >> PAGE_SHIFT) / csi->nr_channels; + dimm->grain = SYNPS_EDAC_ERR_GRAIN; diff --git a/queue-5.14/irqchip-armada-370-xp-fix-ack-eoi-breakage.patch b/queue-5.14/irqchip-armada-370-xp-fix-ack-eoi-breakage.patch new file mode 100644 index 00000000000..b9946be87d6 --- /dev/null +++ b/queue-5.14/irqchip-armada-370-xp-fix-ack-eoi-breakage.patch @@ -0,0 +1,49 @@ +From 2a7313dc81e88adc7bb09d0f056985fa8afc2b89 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Wed, 22 Sep 2021 14:19:41 +0100 +Subject: irqchip/armada-370-xp: Fix ack/eoi breakage + +From: Marc Zyngier + +commit 2a7313dc81e88adc7bb09d0f056985fa8afc2b89 upstream. + +When converting the driver to using handle_percpu_devid_irq, +we forgot to repaint the irq_eoi() callback into irq_ack(), +as handle_percpu_devid_fasteoi_ipi() was actually using EOI +really early in the handling. Yes this was a stupid idea. + +Fix this by using the HW ack method as irq_ack(). + +Fixes: e52e73b7e9f7 ("irqchip/armada-370-xp: Make IPIs use handle_percpu_devid_irq()") +Reported-by: Steffen Trumtrar +Tested-by: Steffen Trumtrar +Signed-off-by: Marc Zyngier +Cc: Valentin Schneider +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/87tuiexq5f.fsf@pengutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-armada-370-xp.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/irqchip/irq-armada-370-xp.c ++++ b/drivers/irqchip/irq-armada-370-xp.c +@@ -359,16 +359,16 @@ static void armada_370_xp_ipi_send_mask( + ARMADA_370_XP_SW_TRIG_INT_OFFS); + } + +-static void armada_370_xp_ipi_eoi(struct irq_data *d) ++static void armada_370_xp_ipi_ack(struct irq_data *d) + { + writel(~BIT(d->hwirq), per_cpu_int_base + ARMADA_370_XP_IN_DRBEL_CAUSE_OFFS); + } + + static struct irq_chip ipi_irqchip = { + .name = "IPI", ++ .irq_ack = armada_370_xp_ipi_ack, + .irq_mask = armada_370_xp_ipi_mask, + .irq_unmask = armada_370_xp_ipi_unmask, +- .irq_eoi = armada_370_xp_ipi_eoi, + .ipi_send_mask = armada_370_xp_ipi_send_mask, + }; + diff --git a/queue-5.14/series b/queue-5.14/series index ff87b8bdb33..af016a9bf8c 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -147,3 +147,8 @@ net-6pack-fix-tx-timeout-and-slot-time.patch spi-fix-tegra20-build-with-config_pm-n.patch libperf-evsel-make-use-of-fd-robust.patch revert-drm-vc4-hdmi-runtime-pm-changes.patch +edac-synopsys-fix-wrong-value-type-assignment-for-edac_mode.patch +edac-dmc520-assign-the-proper-type-to-dimm-edac_mode.patch +x86-setup-call-early_reserve_memory-earlier.patch +thermal-drivers-int340x-do-not-set-a-wrong-tcc-offset-on-resume.patch +irqchip-armada-370-xp-fix-ack-eoi-breakage.patch diff --git a/queue-5.14/thermal-drivers-int340x-do-not-set-a-wrong-tcc-offset-on-resume.patch b/queue-5.14/thermal-drivers-int340x-do-not-set-a-wrong-tcc-offset-on-resume.patch new file mode 100644 index 00000000000..d945ab9fdb9 --- /dev/null +++ b/queue-5.14/thermal-drivers-int340x-do-not-set-a-wrong-tcc-offset-on-resume.patch @@ -0,0 +1,68 @@ +From 8b4bd256674720709a9d858a219fcac6f2f253b5 Mon Sep 17 00:00:00 2001 +From: Antoine Tenart +Date: Thu, 9 Sep 2021 10:56:12 +0200 +Subject: thermal/drivers/int340x: Do not set a wrong tcc offset on resume + +From: Antoine Tenart + +commit 8b4bd256674720709a9d858a219fcac6f2f253b5 upstream. + +After upgrading to Linux 5.13.3 I noticed my laptop would shutdown due +to overheat (when it should not). It turned out this was due to commit +fe6a6de6692e ("thermal/drivers/int340x/processor_thermal: Fix tcc setting"). + +What happens is this drivers uses a global variable to keep track of the +tcc offset (tcc_offset_save) and uses it on resume. The issue is this +variable is initialized to 0, but is only set in +tcc_offset_degree_celsius_store, i.e. when the tcc offset is explicitly +set by userspace. If that does not happen, the resume path will set the +offset to 0 (in my case the h/w default being 3, the offset would become +too low after a suspend/resume cycle). + +The issue did not arise before commit fe6a6de6692e, as the function +setting the offset would return if the offset was 0. This is no longer +the case (rightfully). + +Fix this by not applying the offset if it wasn't saved before, reverting +back to the old logic. A better approach will come later, but this will +be easier to apply to stable kernels. + +The logic to restore the offset after a resume was there long before +commit fe6a6de6692e, but as a value of 0 was considered invalid I'm +referencing the commit that made the issue possible in the Fixes tag +instead. + +Fixes: fe6a6de6692e ("thermal/drivers/int340x/processor_thermal: Fix tcc setting") +Cc: stable@vger.kernel.org +Cc: Srinivas Pandruvada +Signed-off-by: Antoine Tenart +Signed-off-by: Daniel Lezcano +Reviewed-by: Srinivas Pandruvada +Tested-by: Srinivas Pandruvada +Link: https://lore.kernel.org/r/20210909085613.5577-2-atenart@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/intel/int340x_thermal/processor_thermal_device.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c ++++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_device.c +@@ -107,7 +107,7 @@ static int tcc_offset_update(unsigned in + return 0; + } + +-static unsigned int tcc_offset_save; ++static int tcc_offset_save = -1; + + static ssize_t tcc_offset_degree_celsius_store(struct device *dev, + struct device_attribute *attr, const char *buf, +@@ -352,7 +352,8 @@ int proc_thermal_resume(struct device *d + proc_dev = dev_get_drvdata(dev); + proc_thermal_read_ppcc(proc_dev); + +- tcc_offset_update(tcc_offset_save); ++ if (tcc_offset_save >= 0) ++ tcc_offset_update(tcc_offset_save); + + return 0; + } diff --git a/queue-5.14/x86-setup-call-early_reserve_memory-earlier.patch b/queue-5.14/x86-setup-call-early_reserve_memory-earlier.patch new file mode 100644 index 00000000000..4aae6b0f836 --- /dev/null +++ b/queue-5.14/x86-setup-call-early_reserve_memory-earlier.patch @@ -0,0 +1,76 @@ +From 8aa83e6395ce047a506f0b16edca45f36c1ae7f8 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Mon, 20 Sep 2021 14:04:21 +0200 +Subject: x86/setup: Call early_reserve_memory() earlier +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Juergen Gross + +commit 8aa83e6395ce047a506f0b16edca45f36c1ae7f8 upstream. + +Commit in Fixes introduced early_reserve_memory() to do all needed +initial memblock_reserve() calls in one function. Unfortunately, the call +of early_reserve_memory() is done too late for Xen dom0, as in some +cases a Xen hook called by e820__memory_setup() will need those memory +reservations to have happened already. + +Move the call of early_reserve_memory() before the call of +e820__memory_setup() in order to avoid such problems. + +Fixes: a799c2bd29d1 ("x86/setup: Consolidate early memory reservations") +Reported-by: Marek Marczykowski-Górecki +Signed-off-by: Juergen Gross +Signed-off-by: Borislav Petkov +Tested-by: Marek Marczykowski-Górecki +Tested-by: Nathan Chancellor +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20210920120421.29276-1-jgross@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/setup.c | 26 ++++++++++++++------------ + 1 file changed, 14 insertions(+), 12 deletions(-) + +--- a/arch/x86/kernel/setup.c ++++ b/arch/x86/kernel/setup.c +@@ -839,6 +839,20 @@ void __init setup_arch(char **cmdline_p) + + x86_init.oem.arch_setup(); + ++ /* ++ * Do some memory reservations *before* memory is added to memblock, so ++ * memblock allocations won't overwrite it. ++ * ++ * After this point, everything still needed from the boot loader or ++ * firmware or kernel text should be early reserved or marked not RAM in ++ * e820. All other memory is free game. ++ * ++ * This call needs to happen before e820__memory_setup() which calls the ++ * xen_memory_setup() on Xen dom0 which relies on the fact that those ++ * early reservations have happened already. ++ */ ++ early_reserve_memory(); ++ + iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1; + e820__memory_setup(); + parse_setup_data(); +@@ -885,18 +899,6 @@ void __init setup_arch(char **cmdline_p) + + parse_early_param(); + +- /* +- * Do some memory reservations *before* memory is added to +- * memblock, so memblock allocations won't overwrite it. +- * Do it after early param, so we could get (unlikely) panic from +- * serial. +- * +- * After this point everything still needed from the boot loader or +- * firmware or kernel text should be early reserved or marked not +- * RAM in e820. All other memory is free game. +- */ +- early_reserve_memory(); +- + #ifdef CONFIG_MEMORY_HOTPLUG + /* + * Memory used by the kernel cannot be hot-removed because Linux -- 2.47.3