From: Greg Kroah-Hartman Date: Mon, 9 May 2022 08:13:09 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.9.313~103 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1fd7d9baee2e12816e458d419686310a559c4cf7;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch revert-parisc-fix-patch-code-locking-and-flushing.patch --- diff --git a/queue-5.4/alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch b/queue-5.4/alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch new file mode 100644 index 00000000000..8a720c039c4 --- /dev/null +++ b/queue-5.4/alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch @@ -0,0 +1,34 @@ +From eb9d84b0ffe39893cb23b0b6712bbe3637fa25fa Mon Sep 17 00:00:00 2001 +From: Takashi Sakamoto +Date: Sun, 24 Apr 2022 19:24:28 +0900 +Subject: ALSA: fireworks: fix wrong return count shorter than expected by 4 bytes + +From: Takashi Sakamoto + +commit eb9d84b0ffe39893cb23b0b6712bbe3637fa25fa upstream. + +ALSA fireworks driver has a bug in its initial state to return count +shorter than expected by 4 bytes to userspace applications when handling +response frame for Echo Audio Fireworks transaction. It's due to missing +addition of the size for the type of event in ALSA firewire stack. + +Fixes: 555e8a8f7f14 ("ALSA: fireworks: Add command/response functionality into hwdep interface") +Cc: +Signed-off-by: Takashi Sakamoto +Link: https://lore.kernel.org/r/20220424102428.21109-1-o-takashi@sakamocchi.jp +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/firewire/fireworks/fireworks_hwdep.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/firewire/fireworks/fireworks_hwdep.c ++++ b/sound/firewire/fireworks/fireworks_hwdep.c +@@ -34,6 +34,7 @@ hwdep_read_resp_buf(struct snd_efw *efw, + type = SNDRV_FIREWIRE_EVENT_EFW_RESPONSE; + if (copy_to_user(buf, &type, sizeof(type))) + return -EFAULT; ++ count += sizeof(type); + remained -= sizeof(type); + buf += sizeof(type); + diff --git a/queue-5.4/mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch b/queue-5.4/mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch new file mode 100644 index 00000000000..49ea124a058 --- /dev/null +++ b/queue-5.4/mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch @@ -0,0 +1,106 @@ +From f0a6c68f69981214cb7858738dd2bc81475111f7 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Sun, 24 Apr 2022 12:46:23 +0100 +Subject: MIPS: Fix CP0 counter erratum detection for R4k CPUs +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Maciej W. Rozycki + +commit f0a6c68f69981214cb7858738dd2bc81475111f7 upstream. + +Fix the discrepancy between the two places we check for the CP0 counter +erratum in along with the incorrect comparison of the R4400 revision +number against 0x30 which matches none and consistently consider all +R4000 and R4400 processors affected, as documented in processor errata +publications[1][2][3], following the mapping between CP0 PRId register +values and processor models: + + PRId | Processor Model +---------+-------------------- +00000422 | R4000 Revision 2.2 +00000430 | R4000 Revision 3.0 +00000440 | R4400 Revision 1.0 +00000450 | R4400 Revision 2.0 +00000460 | R4400 Revision 3.0 + +No other revision of either processor has ever been spotted. + +Contrary to what has been stated in commit ce202cbb9e0b ("[MIPS] Assume +R4000/R4400 newer than 3.0 don't have the mfc0 count bug") marking the +CP0 counter as buggy does not preclude it from being used as either a +clock event or a clock source device. It just cannot be used as both at +a time, because in that case clock event interrupts will be occasionally +lost, and the use as a clock event device takes precedence. + +Compare against 0x4ff in `can_use_mips_counter' so that a single machine +instruction is produced. + +References: + +[1] "MIPS R4000PC/SC Errata, Processor Revision 2.2 and 3.0", MIPS + Technologies Inc., May 10, 1994, Erratum 53, p.13 + +[2] "MIPS R4400PC/SC Errata, Processor Revision 1.0", MIPS Technologies + Inc., February 9, 1994, Erratum 21, p.4 + +[3] "MIPS R4400PC/SC Errata, Processor Revision 2.0 & 3.0", MIPS + Technologies Inc., January 24, 1995, Erratum 14, p.3 + +Signed-off-by: Maciej W. Rozycki +Fixes: ce202cbb9e0b ("[MIPS] Assume R4000/R4400 newer than 3.0 don't have the mfc0 count bug") +Cc: stable@vger.kernel.org # v2.6.24+ +Reviewed-by: Philippe Mathieu-Daudé +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/include/asm/timex.h | 8 ++++---- + arch/mips/kernel/time.c | 11 +++-------- + 2 files changed, 7 insertions(+), 12 deletions(-) + +--- a/arch/mips/include/asm/timex.h ++++ b/arch/mips/include/asm/timex.h +@@ -40,9 +40,9 @@ + typedef unsigned int cycles_t; + + /* +- * On R4000/R4400 before version 5.0 an erratum exists such that if the +- * cycle counter is read in the exact moment that it is matching the +- * compare register, no interrupt will be generated. ++ * On R4000/R4400 an erratum exists such that if the cycle counter is ++ * read in the exact moment that it is matching the compare register, ++ * no interrupt will be generated. + * + * There is a suggested workaround and also the erratum can't strike if + * the compare interrupt isn't being used as the clock source device. +@@ -63,7 +63,7 @@ static inline int can_use_mips_counter(u + if (!__builtin_constant_p(cpu_has_counter)) + asm volatile("" : "=m" (cpu_data[0].options)); + if (likely(cpu_has_counter && +- prid >= (PRID_IMP_R4000 | PRID_REV_ENCODE_44(5, 0)))) ++ prid > (PRID_IMP_R4000 | PRID_REV_ENCODE_44(15, 15)))) + return 1; + else + return 0; +--- a/arch/mips/kernel/time.c ++++ b/arch/mips/kernel/time.c +@@ -141,15 +141,10 @@ static __init int cpu_has_mfc0_count_bug + case CPU_R4400MC: + /* + * The published errata for the R4400 up to 3.0 say the CPU +- * has the mfc0 from count bug. ++ * has the mfc0 from count bug. This seems the last version ++ * produced. + */ +- if ((current_cpu_data.processor_id & 0xff) <= 0x30) +- return 1; +- +- /* +- * we assume newer revisions are ok +- */ +- return 0; ++ return 1; + } + + return 0; diff --git a/queue-5.4/parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch b/queue-5.4/parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch new file mode 100644 index 00000000000..947a080e9c5 --- /dev/null +++ b/queue-5.4/parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch @@ -0,0 +1,32 @@ +From 5b89966bc96a06f6ad65f64ae4b0461918fcc9d3 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Sun, 3 Apr 2022 21:57:51 +0200 +Subject: parisc: Merge model and model name into one line in /proc/cpuinfo + +From: Helge Deller + +commit 5b89966bc96a06f6ad65f64ae4b0461918fcc9d3 upstream. + +The Linux tool "lscpu" shows the double amount of CPUs if we have +"model" and "model name" in two different lines in /proc/cpuinfo. +This change combines the model and the model name into one line. + +Signed-off-by: Helge Deller +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/kernel/processor.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/arch/parisc/kernel/processor.c ++++ b/arch/parisc/kernel/processor.c +@@ -419,8 +419,7 @@ show_cpuinfo (struct seq_file *m, void * + } + seq_printf(m, " (0x%02lx)\n", boot_cpu_data.pdc.capabilities); + +- seq_printf(m, "model\t\t: %s\n" +- "model name\t: %s\n", ++ seq_printf(m, "model\t\t: %s - %s\n", + boot_cpu_data.pdc.sys_model_name, + cpuinfo->dev ? + cpuinfo->dev->name : "Unknown"); diff --git a/queue-5.4/revert-parisc-fix-patch-code-locking-and-flushing.patch b/queue-5.4/revert-parisc-fix-patch-code-locking-and-flushing.patch new file mode 100644 index 00000000000..9bcba6fb134 --- /dev/null +++ b/queue-5.4/revert-parisc-fix-patch-code-locking-and-flushing.patch @@ -0,0 +1,83 @@ +From 6c800d7f55fcd78e17deae5ae4374d8e73482c13 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Sun, 8 May 2022 10:18:40 +0200 +Subject: Revert "parisc: Fix patch code locking and flushing" + +From: Helge Deller + +commit 6c800d7f55fcd78e17deae5ae4374d8e73482c13 upstream. + +This reverts commit a9fe7fa7d874a536e0540469f314772c054a0323. + +Leads to segfaults on 32bit kernel. + +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/kernel/patch.c | 25 ++++++++++++++----------- + 1 file changed, 14 insertions(+), 11 deletions(-) + +--- a/arch/parisc/kernel/patch.c ++++ b/arch/parisc/kernel/patch.c +@@ -40,7 +40,10 @@ static void __kprobes *patch_map(void *a + + *need_unmap = 1; + set_fixmap(fixmap, page_to_phys(page)); +- raw_spin_lock_irqsave(&patch_lock, *flags); ++ if (flags) ++ raw_spin_lock_irqsave(&patch_lock, *flags); ++ else ++ __acquire(&patch_lock); + + return (void *) (__fix_to_virt(fixmap) + (uintaddr & ~PAGE_MASK)); + } +@@ -49,7 +52,10 @@ static void __kprobes patch_unmap(int fi + { + clear_fixmap(fixmap); + +- raw_spin_unlock_irqrestore(&patch_lock, *flags); ++ if (flags) ++ raw_spin_unlock_irqrestore(&patch_lock, *flags); ++ else ++ __release(&patch_lock); + } + + void __kprobes __patch_text_multiple(void *addr, u32 *insn, unsigned int len) +@@ -61,9 +67,8 @@ void __kprobes __patch_text_multiple(voi + int mapped; + + /* Make sure we don't have any aliases in cache */ +- flush_kernel_dcache_range_asm(start, end); +- flush_kernel_icache_range_asm(start, end); +- flush_tlb_kernel_range(start, end); ++ flush_kernel_vmap_range(addr, len); ++ flush_icache_range(start, end); + + p = fixmap = patch_map(addr, FIX_TEXT_POKE0, &flags, &mapped); + +@@ -76,10 +81,8 @@ void __kprobes __patch_text_multiple(voi + * We're crossing a page boundary, so + * need to remap + */ +- flush_kernel_dcache_range_asm((unsigned long)fixmap, +- (unsigned long)p); +- flush_tlb_kernel_range((unsigned long)fixmap, +- (unsigned long)p); ++ flush_kernel_vmap_range((void *)fixmap, ++ (p-fixmap) * sizeof(*p)); + if (mapped) + patch_unmap(FIX_TEXT_POKE0, &flags); + p = fixmap = patch_map(addr, FIX_TEXT_POKE0, &flags, +@@ -87,10 +90,10 @@ void __kprobes __patch_text_multiple(voi + } + } + +- flush_kernel_dcache_range_asm((unsigned long)fixmap, (unsigned long)p); +- flush_tlb_kernel_range((unsigned long)fixmap, (unsigned long)p); ++ flush_kernel_vmap_range((void *)fixmap, (p-fixmap) * sizeof(*p)); + if (mapped) + patch_unmap(FIX_TEXT_POKE0, &flags); ++ flush_icache_range(start, end); + } + + void __kprobes __patch_text(void *addr, u32 insn) diff --git a/queue-5.4/series b/queue-5.4/series new file mode 100644 index 00000000000..58ec7bb068c --- /dev/null +++ b/queue-5.4/series @@ -0,0 +1,4 @@ +mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch +revert-parisc-fix-patch-code-locking-and-flushing.patch +parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch +alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch