]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 26 May 2023 19:07:10 +0000 (20:07 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 26 May 2023 19:07:10 +0000 (20:07 +0100)
added patches:
alsa-hda-ca0132-add-quirk-for-evga-x299-dark.patch
alsa-hda-fix-unhandled-register-update-during-auto-suspend-period.patch
m68k-move-signal-frame-following-exception-on-68020-030.patch
parisc-allow-to-reboot-machine-after-system-halt.patch
x86-mm-avoid-incomplete-global-invlpg-flushes.patch

queue-4.19/alsa-hda-ca0132-add-quirk-for-evga-x299-dark.patch [new file with mode: 0644]
queue-4.19/alsa-hda-fix-unhandled-register-update-during-auto-suspend-period.patch [new file with mode: 0644]
queue-4.19/m68k-move-signal-frame-following-exception-on-68020-030.patch [new file with mode: 0644]
queue-4.19/parisc-allow-to-reboot-machine-after-system-halt.patch [new file with mode: 0644]
queue-4.19/series
queue-4.19/x86-mm-avoid-incomplete-global-invlpg-flushes.patch [new file with mode: 0644]

diff --git a/queue-4.19/alsa-hda-ca0132-add-quirk-for-evga-x299-dark.patch b/queue-4.19/alsa-hda-ca0132-add-quirk-for-evga-x299-dark.patch
new file mode 100644 (file)
index 0000000..e3c8878
--- /dev/null
@@ -0,0 +1,33 @@
+From 7843380d07bbeffd3ce6504e73cf61f840ae76ca Mon Sep 17 00:00:00 2001
+From: Adam Stylinski <kungfujesus06@gmail.com>
+Date: Sun, 21 May 2023 10:52:23 -0400
+Subject: ALSA: hda/ca0132: add quirk for EVGA X299 DARK
+
+From: Adam Stylinski <kungfujesus06@gmail.com>
+
+commit 7843380d07bbeffd3ce6504e73cf61f840ae76ca upstream.
+
+This quirk is necessary for surround and other DSP effects to work
+with the onboard ca0132 based audio chipset for the EVGA X299 dark
+mainboard.
+
+Signed-off-by: Adam Stylinski <kungfujesus06@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=67071
+Link: https://lore.kernel.org/r/ZGopOe19T1QOwizS@eggsbenedict.adamsnet
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_ca0132.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_ca0132.c
++++ b/sound/pci/hda/patch_ca0132.c
+@@ -1070,6 +1070,7 @@ static const struct snd_pci_quirk ca0132
+       SND_PCI_QUIRK(0x1458, 0xA026, "Gigabyte G1.Sniper Z97", QUIRK_R3DI),
+       SND_PCI_QUIRK(0x1458, 0xA036, "Gigabyte GA-Z170X-Gaming 7", QUIRK_R3DI),
+       SND_PCI_QUIRK(0x3842, 0x1038, "EVGA X99 Classified", QUIRK_R3DI),
++      SND_PCI_QUIRK(0x3842, 0x104b, "EVGA X299 Dark", QUIRK_R3DI),
+       SND_PCI_QUIRK(0x3842, 0x1055, "EVGA Z390 DARK", QUIRK_R3DI),
+       SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D),
+       {}
diff --git a/queue-4.19/alsa-hda-fix-unhandled-register-update-during-auto-suspend-period.patch b/queue-4.19/alsa-hda-fix-unhandled-register-update-during-auto-suspend-period.patch
new file mode 100644 (file)
index 0000000..68ec698
--- /dev/null
@@ -0,0 +1,67 @@
+From 81302b1c7c997e8a56c1c2fc63a296ebeb0cd2d0 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 18 May 2023 13:35:20 +0200
+Subject: ALSA: hda: Fix unhandled register update during auto-suspend period
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 81302b1c7c997e8a56c1c2fc63a296ebeb0cd2d0 upstream.
+
+It's reported that the recording started right after the driver probe
+doesn't work properly, and it turned out that this is related with the
+codec auto-suspend.  Namely, after the probe phase, the usage count
+goes zero, and the auto-suspend is programmed, but the codec is kept
+still active until the auto-suspend expiration.  When an application
+(e.g. alsactl) updates the mixer values at this moment, the values are
+cached but not actually written.  Then, starting arecord thereafter
+also results in the silence because of the missing unmute.
+
+The root cause is the handling of "lazy update" mode; when a mixer
+value is updated *after* the suspend, it should update only the cache
+and exits.  At the resume, the cached value is written to the device,
+in turn.  The problem is that the current code misinterprets the state
+of auto-suspend as if it were already suspended.
+
+Although we can add the check of the actual device state after
+pm_runtime_get_if_in_use() for catching the missing state, this won't
+suffice; the second call of regmap_update_bits_check() will skip
+writing the register because the cache has been already updated by the
+first call.  So we'd need fixes in two different places.
+
+OTOH, a simpler fix is to replace pm_runtime_get_if_in_use() with
+pm_runtime_get_if_active() (with ign_usage_count=true).  This change
+implies that the driver takes the pm refcount if the device is still
+in ACTIVE state and continues the processing.  A small caveat is that
+this will leave the auto-suspend timer.  But, since the timer callback
+itself checks the device state and aborts gracefully when it's active,
+this won't be any substantial problem.
+
+Long story short: we address the missing register-write problem just
+by replacing the pm_runtime_*() call in snd_hda_keep_power_up().
+
+Fixes: fc4f000bf8c0 ("ALSA: hda - Fix unexpected resume through regmap code path")
+Reported-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
+Closes: https://lore.kernel.org/r/a7478636-af11-92ab-731c-9b13c582a70d@linux.intel.com
+Suggested-by: Cezary Rojewski <cezary.rojewski@intel.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230518113520.15213-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/hda/hdac_device.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/hda/hdac_device.c
++++ b/sound/hda/hdac_device.c
+@@ -597,7 +597,7 @@ EXPORT_SYMBOL_GPL(snd_hdac_power_up_pm);
+ int snd_hdac_keep_power_up(struct hdac_device *codec)
+ {
+       if (!atomic_inc_not_zero(&codec->in_pm)) {
+-              int ret = pm_runtime_get_if_in_use(&codec->dev);
++              int ret = pm_runtime_get_if_active(&codec->dev, true);
+               if (!ret)
+                       return -1;
+               if (ret < 0)
diff --git a/queue-4.19/m68k-move-signal-frame-following-exception-on-68020-030.patch b/queue-4.19/m68k-move-signal-frame-following-exception-on-68020-030.patch
new file mode 100644 (file)
index 0000000..ca4edaf
--- /dev/null
@@ -0,0 +1,90 @@
+From b845b574f86dcb6a70dfa698aa87a237b0878d2a Mon Sep 17 00:00:00 2001
+From: Finn Thain <fthain@linux-m68k.org>
+Date: Sat, 6 May 2023 19:38:12 +1000
+Subject: m68k: Move signal frame following exception on 68020/030
+
+From: Finn Thain <fthain@linux-m68k.org>
+
+commit b845b574f86dcb6a70dfa698aa87a237b0878d2a upstream.
+
+On 68030/020, an instruction such as, moveml %a2-%a3/%a5,%sp@- may cause
+a stack page fault during instruction execution (i.e. not at an
+instruction boundary) and produce a format 0xB exception frame.
+
+In this situation, the value of USP will be unreliable.  If a signal is
+to be delivered following the exception, this USP value is used to
+calculate the location for a signal frame.  This can result in a
+corrupted user stack.
+
+The corruption was detected in dash (actually in glibc) where it showed
+up as an intermittent "stack smashing detected" message and crash
+following signal delivery for SIGCHLD.
+
+It was hard to reproduce that failure because delivery of the signal
+raced with the page fault and because the kernel places an unpredictable
+gap of up to 7 bytes between the USP and the signal frame.
+
+A format 0xB exception frame can be produced by a bus error or an
+address error.  The 68030 Users Manual says that address errors occur
+immediately upon detection during instruction prefetch.  The instruction
+pipeline allows prefetch to overlap with other instructions, which means
+an address error can arise during the execution of a different
+instruction.  So it seems likely that this patch may help in the address
+error case also.
+
+Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
+Link: https://lore.kernel.org/all/CAMuHMdW3yD22_ApemzW_6me3adq6A458u1_F0v-1EYwK_62jPA@mail.gmail.com/
+Cc: Michael Schmitz <schmitzmic@gmail.com>
+Cc: Andreas Schwab <schwab@linux-m68k.org>
+Cc: stable@vger.kernel.org
+Co-developed-by: Michael Schmitz <schmitzmic@gmail.com>
+Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
+Signed-off-by: Finn Thain <fthain@linux-m68k.org>
+Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Link: https://lore.kernel.org/r/9e66262a754fcba50208aa424188896cc52a1dd1.1683365892.git.fthain@linux-m68k.org
+Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/m68k/kernel/signal.c |   14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+--- a/arch/m68k/kernel/signal.c
++++ b/arch/m68k/kernel/signal.c
+@@ -882,11 +882,17 @@ static inline int rt_setup_ucontext(stru
+ }
+ static inline void __user *
+-get_sigframe(struct ksignal *ksig, size_t frame_size)
++get_sigframe(struct ksignal *ksig, struct pt_regs *tregs, size_t frame_size)
+ {
+       unsigned long usp = sigsp(rdusp(), ksig);
++      unsigned long gap = 0;
+-      return (void __user *)((usp - frame_size) & -8UL);
++      if (CPU_IS_020_OR_030 && tregs->format == 0xb) {
++              /* USP is unreliable so use worst-case value */
++              gap = 256;
++      }
++
++      return (void __user *)((usp - gap - frame_size) & -8UL);
+ }
+ static int setup_frame(struct ksignal *ksig, sigset_t *set,
+@@ -904,7 +910,7 @@ static int setup_frame(struct ksignal *k
+               return -EFAULT;
+       }
+-      frame = get_sigframe(ksig, sizeof(*frame) + fsize);
++      frame = get_sigframe(ksig, tregs, sizeof(*frame) + fsize);
+       if (fsize)
+               err |= copy_to_user (frame + 1, regs + 1, fsize);
+@@ -975,7 +981,7 @@ static int setup_rt_frame(struct ksignal
+               return -EFAULT;
+       }
+-      frame = get_sigframe(ksig, sizeof(*frame));
++      frame = get_sigframe(ksig, tregs, sizeof(*frame));
+       if (fsize)
+               err |= copy_to_user (&frame->uc.uc_extra, regs + 1, fsize);
diff --git a/queue-4.19/parisc-allow-to-reboot-machine-after-system-halt.patch b/queue-4.19/parisc-allow-to-reboot-machine-after-system-halt.patch
new file mode 100644 (file)
index 0000000..8cb46b3
--- /dev/null
@@ -0,0 +1,43 @@
+From 2028315cf59bb899a5ac7e87dc48ecb8fac7ac24 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Mon, 22 May 2023 22:57:30 +0200
+Subject: parisc: Allow to reboot machine after system halt
+
+From: Helge Deller <deller@gmx.de>
+
+commit 2028315cf59bb899a5ac7e87dc48ecb8fac7ac24 upstream.
+
+In case a machine can't power-off itself on system shutdown,
+allow the user to reboot it by pressing the RETURN key.
+
+Cc: <stable@vger.kernel.org> # v4.14+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/process.c |   11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+--- a/arch/parisc/kernel/process.c
++++ b/arch/parisc/kernel/process.c
+@@ -138,13 +138,18 @@ void machine_power_off(void)
+       /* It seems we have no way to power the system off via
+        * software. The user has to press the button himself. */
+-      printk(KERN_EMERG "System shut down completed.\n"
+-             "Please power this system off now.");
++      printk("Power off or press RETURN to reboot.\n");
+       /* prevent soft lockup/stalled CPU messages for endless loop. */
+       rcu_sysrq_start();
+       lockup_detector_soft_poweroff();
+-      for (;;);
++      while (1) {
++              /* reboot if user presses RETURN key */
++              if (pdc_iodc_getc() == 13) {
++                      printk("Rebooting...\n");
++                      machine_restart(NULL);
++              }
++      }
+ }
+ void (*pm_power_off)(void);
index efe7752f3847cc0bff05b8df13af535cf3420bd0..a3f2cdbe8c8e042da488d62615a142a8cded87bf 100644 (file)
@@ -103,3 +103,8 @@ s390-qdio-fix-do_sqbs-inline-assembly-constraint.patch
 spi-spi-fsl-spi-automatically-adapt-bits-per-word-in-cpu-mode.patch
 spi-fsl-spi-re-organise-transfer-bits_per_word-adaptation.patch
 spi-fsl-cpm-use-16-bit-mode-for-large-transfers-with-even-size.patch
+x86-mm-avoid-incomplete-global-invlpg-flushes.patch
+alsa-hda-ca0132-add-quirk-for-evga-x299-dark.patch
+alsa-hda-fix-unhandled-register-update-during-auto-suspend-period.patch
+m68k-move-signal-frame-following-exception-on-68020-030.patch
+parisc-allow-to-reboot-machine-after-system-halt.patch
diff --git a/queue-4.19/x86-mm-avoid-incomplete-global-invlpg-flushes.patch b/queue-4.19/x86-mm-avoid-incomplete-global-invlpg-flushes.patch
new file mode 100644 (file)
index 0000000..b957640
--- /dev/null
@@ -0,0 +1,85 @@
+From ce0b15d11ad837fbacc5356941712218e38a0a83 Mon Sep 17 00:00:00 2001
+From: Dave Hansen <dave.hansen@linux.intel.com>
+Date: Tue, 16 May 2023 12:24:25 -0700
+Subject: x86/mm: Avoid incomplete Global INVLPG flushes
+
+From: Dave Hansen <dave.hansen@linux.intel.com>
+
+commit ce0b15d11ad837fbacc5356941712218e38a0a83 upstream.
+
+The INVLPG instruction is used to invalidate TLB entries for a
+specified virtual address.  When PCIDs are enabled, INVLPG is supposed
+to invalidate TLB entries for the specified address for both the
+current PCID *and* Global entries.  (Note: Only kernel mappings set
+Global=1.)
+
+Unfortunately, some INVLPG implementations can leave Global
+translations unflushed when PCIDs are enabled.
+
+As a workaround, never enable PCIDs on affected processors.
+
+I expect there to eventually be microcode mitigations to replace this
+software workaround.  However, the exact version numbers where that
+will happen are not known today.  Once the version numbers are set in
+stone, the processor list can be tweaked to only disable PCIDs on
+affected processors with affected microcode.
+
+Note: if anyone wants a quick fix that doesn't require patching, just
+stick 'nopcid' on your kernel command-line.
+
+Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/init.c |   25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/arch/x86/mm/init.c
++++ b/arch/x86/mm/init.c
+@@ -9,6 +9,7 @@
+ #include <linux/kmemleak.h>
+ #include <asm/set_memory.h>
++#include <asm/cpu_device_id.h>
+ #include <asm/e820/api.h>
+ #include <asm/init.h>
+ #include <asm/page.h>
+@@ -207,6 +208,24 @@ static void __init probe_page_size_mask(
+       }
+ }
++#define INTEL_MATCH(_model) { .vendor  = X86_VENDOR_INTEL,    \
++                            .family  = 6,                     \
++                            .model = _model,                  \
++                          }
++/*
++ * INVLPG may not properly flush Global entries
++ * on these CPUs when PCIDs are enabled.
++ */
++static const struct x86_cpu_id invlpg_miss_ids[] = {
++      INTEL_MATCH(INTEL_FAM6_ALDERLAKE   ),
++      INTEL_MATCH(INTEL_FAM6_ALDERLAKE_L ),
++      INTEL_MATCH(INTEL_FAM6_ALDERLAKE_N ),
++      INTEL_MATCH(INTEL_FAM6_RAPTORLAKE  ),
++      INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_P),
++      INTEL_MATCH(INTEL_FAM6_RAPTORLAKE_S),
++      {}
++};
++
+ static void setup_pcid(void)
+ {
+       if (!IS_ENABLED(CONFIG_X86_64))
+@@ -215,6 +234,12 @@ static void setup_pcid(void)
+       if (!boot_cpu_has(X86_FEATURE_PCID))
+               return;
++      if (x86_match_cpu(invlpg_miss_ids)) {
++              pr_info("Incomplete global flushes, disabling PCID");
++              setup_clear_cpu_cap(X86_FEATURE_PCID);
++              return;
++      }
++
+       if (boot_cpu_has(X86_FEATURE_PGE)) {
+               /*
+                * This can't be cr4_set_bits_and_update_boot() -- the