From: Greg Kroah-Hartman Date: Mon, 9 May 2022 08:21:47 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v4.9.313~98 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ea68711965db2451d4ab0781b66191bf4b82c05c;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-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 --- diff --git a/queue-4.14/alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch b/queue-4.14/alsa-fireworks-fix-wrong-return-count-shorter-than-expected-by-4-bytes.patch new file mode 100644 index 00000000000..9a9ad64ad25 --- /dev/null +++ b/queue-4.14/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 +@@ -35,6 +35,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-4.14/mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch b/queue-4.14/mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.patch new file mode 100644 index 00000000000..391250caac9 --- /dev/null +++ b/queue-4.14/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 +@@ -155,15 +155,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-4.14/parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch b/queue-4.14/parisc-merge-model-and-model-name-into-one-line-in-proc-cpuinfo.patch new file mode 100644 index 00000000000..f9df669f8aa --- /dev/null +++ b/queue-4.14/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 +@@ -408,8 +408,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-4.14/series b/queue-4.14/series index d7e87820fa1..b65268aff09 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -51,3 +51,6 @@ tty-n_gsm-fix-wrong-command-retry-handling.patch tty-n_gsm-fix-wrong-command-frame-length-field-encoding.patch tty-n_gsm-fix-incorrect-ua-handling.patch drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch +mips-fix-cp0-counter-erratum-detection-for-r4k-cpus.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