--- /dev/null
+From 54607282fae6148641a08d81a6e0953b541249c7 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Thu, 16 Sep 2021 10:44:06 +0200
+Subject: EDAC/dmc520: Assign the proper type to dimm->edac_mode
+
+From: Borislav Petkov <bp@suse.de>
+
+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 <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210916085258.7544-1-bp@alien8.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+ }
--- /dev/null
+From 5297cfa6bdf93e3889f78f9b482e2a595a376083 Mon Sep 17 00:00:00 2001
+From: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
+Date: Wed, 18 Aug 2021 12:53:14 +0530
+Subject: EDAC/synopsys: Fix wrong value type assignment for edac_mode
+
+From: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
+
+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 <lakshmi.sai.krishna.potthuri@xilinx.com>
+Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20210818072315.15149-1-shubhrajyoti.datta@xilinx.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 2a7313dc81e88adc7bb09d0f056985fa8afc2b89 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Wed, 22 Sep 2021 14:19:41 +0100
+Subject: irqchip/armada-370-xp: Fix ack/eoi breakage
+
+From: Marc Zyngier <maz@kernel.org>
+
+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 <s.trumtrar@pengutronix.de>
+Tested-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Cc: Valentin Schneider <valentin.schneider@arm.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/87tuiexq5f.fsf@pengutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
+ };
+
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
--- /dev/null
+From 8b4bd256674720709a9d858a219fcac6f2f253b5 Mon Sep 17 00:00:00 2001
+From: Antoine Tenart <atenart@kernel.org>
+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 <atenart@kernel.org>
+
+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 <srinivas.pandruvada@linux.intel.com>
+Signed-off-by: Antoine Tenart <atenart@kernel.org>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Tested-by: Srinivas Pandruvada <srinivas.pI andruvada@linux.intel.com>
+Link: https://lore.kernel.org/r/20210909085613.5577-2-atenart@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 8aa83e6395ce047a506f0b16edca45f36c1ae7f8 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+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 <jgross@suse.com>
+
+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 <marmarek@invisiblethingslab.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20210920120421.29276-1-jgross@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
