--- /dev/null
+From ac237c28d5ac1b241d58b1b7b4b9fa10efb22fb5 Mon Sep 17 00:00:00 2001
+From: Alex Stanoev <alex@astanoev.com>
+Date: Sun, 28 Oct 2018 16:55:12 +0000
+Subject: ALSA: ca0106: Disable IZD on SB0570 DAC to fix audio pops
+
+From: Alex Stanoev <alex@astanoev.com>
+
+commit ac237c28d5ac1b241d58b1b7b4b9fa10efb22fb5 upstream.
+
+The Creative Audigy SE (SB0570) card currently exhibits an audible pop
+whenever playback is stopped or resumed, or during silent periods of an
+audio stream. Initialise the IZD bit to the 0 to eliminate these pops.
+
+The Infinite Zero Detection (IZD) feature on the DAC causes the output
+to be shunted to Vcap after 2048 samples of silence. This discharges the
+AC coupling capacitor through the output and causes the aforementioned
+pop/click noise.
+
+The behaviour of the IZD bit is described on page 15 of the WM8768GEDS
+datasheet: "With IZD=1, applying MUTE for 1024 consecutive input samples
+will cause all outputs to be connected directly to VCAP. This also
+happens if 2048 consecutive zero input samples are applied to all 6
+channels, and IZD=0. It will be removed as soon as any channel receives
+a non-zero input". I believe the second sentence might be referring to
+IZD=1 instead of IZD=0 given the observed behaviour of the card.
+
+This change should make the DAC initialisation consistent with
+Creative's Windows driver, as this popping persists when initialising
+the card in Linux and soft rebooting into Windows, but is not present on
+a cold boot to Windows.
+
+Signed-off-by: Alex Stanoev <alex@astanoev.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/ca0106/ca0106.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/ca0106/ca0106.h
++++ b/sound/pci/ca0106/ca0106.h
+@@ -582,7 +582,7 @@
+ #define SPI_PL_BIT_R_R (2<<7) /* right channel = right */
+ #define SPI_PL_BIT_R_C (3<<7) /* right channel = (L+R)/2 */
+ #define SPI_IZD_REG 2
+-#define SPI_IZD_BIT (1<<4) /* infinite zero detect */
++#define SPI_IZD_BIT (0<<4) /* infinite zero detect */
+
+ #define SPI_FMT_REG 3
+ #define SPI_FMT_BIT_RJ (0<<0) /* right justified mode */
--- /dev/null
+From e7bb6ad5685f05685dd8a6a5eda7bfcd14d5f95b Mon Sep 17 00:00:00 2001
+From: Jeremy Cline <jcline@redhat.com>
+Date: Thu, 11 Oct 2018 15:49:17 -0400
+Subject: ALSA: hda - Add mic quirk for the Lenovo G50-30 (17aa:3905)
+
+From: Jeremy Cline <jcline@redhat.com>
+
+commit e7bb6ad5685f05685dd8a6a5eda7bfcd14d5f95b upstream.
+
+The Lenovo G50-30, like other G50 models, has a Conexant codec that
+requires a quirk for its inverted stereo dmic.
+
+Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1249364
+Reported-by: Alexander Ploumistos <alex.ploumistos@gmail.com>
+Tested-by: Alexander Ploumistos <alex.ploumistos@gmail.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Jeremy Cline <jcline@redhat.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/hda/patch_conexant.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -867,6 +867,7 @@ static const struct snd_pci_quirk cxt506
+ SND_PCI_QUIRK(0x17aa, 0x21da, "Lenovo X220", CXT_PINCFG_LENOVO_TP410),
+ SND_PCI_QUIRK(0x17aa, 0x21db, "Lenovo X220-tablet", CXT_PINCFG_LENOVO_TP410),
+ SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo IdeaPad Z560", CXT_FIXUP_MUTE_LED_EAPD),
++ SND_PCI_QUIRK(0x17aa, 0x3905, "Lenovo G50-30", CXT_FIXUP_STEREO_DMIC),
+ SND_PCI_QUIRK(0x17aa, 0x390b, "Lenovo G50-80", CXT_FIXUP_STEREO_DMIC),
+ SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC),
+ SND_PCI_QUIRK(0x17aa, 0x3977, "Lenovo IdeaPad U310", CXT_FIXUP_STEREO_DMIC),
--- /dev/null
+From 1138b6718ff74d2a934459643e3754423d23b5e2 Mon Sep 17 00:00:00 2001
+From: John David Anglin <dave.anglin@bell.net>
+Date: Sat, 6 Oct 2018 13:11:30 -0400
+Subject: parisc: Fix address in HPMC IVA
+
+From: John David Anglin <dave.anglin@bell.net>
+
+commit 1138b6718ff74d2a934459643e3754423d23b5e2 upstream.
+
+Helge noticed that the address of the os_hpmc handler was not being
+correctly calculated in the hpmc macro. As a result, PDCE_CHECK would
+fail to call os_hpmc:
+
+<Cpu2> e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC
+<Cpu2> 37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY
+<Cpu2> f600105e02e00000 fffffff0f0c00000 CC_MC_HPMC_MONARCH_SELECTED
+<Cpu2> 140003b202e00000 000000000000000b CC_ERR_HPMC_STATE_ENTRY
+<Cpu2> 5600100b02e00000 00000000000001a0 CC_MC_OS_HPMC_LEN_ERR
+<Cpu2> 5600106402e00000 fffffff0f0438e70 CC_MC_BR_TO_OS_HPMC_FAILED
+<Cpu2> e800009802e00000 0000000000000000 CC_ERR_CHECK_HPMC
+<Cpu2> 37000f7302e00000 8040004000000000 CC_ERR_CPU_CHECK_SUMMARY
+<Cpu2> 4000109f02e00000 0000000000000000 CC_MC_HPMC_INITIATED
+<Cpu2> 4000101902e00000 0000000000000000 CC_MC_MULTIPLE_HPMCS
+<Cpu2> 030010d502e00000 0000000000000000 CC_CPU_STOP
+
+The address problem can be seen by dumping the fault vector:
+
+0000000040159000 <fault_vector_20>:
+ 40159000: 63 6f 77 73 stb r15,-2447(dp)
+ 40159004: 20 63 61 6e ldil L%b747000,r3
+ 40159008: 20 66 6c 79 ldil L%-1c3b3000,r3
+ ...
+ 40159020: 08 00 02 40 nop
+ 40159024: 20 6e 60 02 ldil L%15d000,r3
+ 40159028: 34 63 00 00 ldo 0(r3),r3
+ 4015902c: e8 60 c0 02 bv,n r0(r3)
+ 40159030: 08 00 02 40 nop
+ 40159034: 00 00 00 00 break 0,0
+ 40159038: c0 00 70 00 bb,*< r0,sar,40159840 <fault_vector_20+0x840>
+ 4015903c: 00 00 00 00 break 0,0
+
+Location 40159038 should contain the physical address of os_hpmc:
+
+000000004015d000 <os_hpmc>:
+ 4015d000: 08 1a 02 43 copy r26,r3
+ 4015d004: 01 c0 08 a4 mfctl iva,r4
+ 4015d008: 48 85 00 68 ldw 34(r4),r5
+
+This patch moves the address setup into initialize_ivt to resolve the
+above problem. I tested the change by dumping the HPMC entry after setup:
+
+0000000040209020: 8000240
+0000000040209024: 206a2004
+0000000040209028: 34630ac0
+000000004020902c: e860c002
+0000000040209030: 8000240
+0000000040209034: 1bdddce6
+0000000040209038: 15d000
+000000004020903c: 1a0
+
+Signed-off-by: John David Anglin <dave.anglin@bell.net>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/kernel/entry.S | 2 +-
+ arch/parisc/kernel/traps.c | 3 ++-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/parisc/kernel/entry.S
++++ b/arch/parisc/kernel/entry.S
+@@ -185,7 +185,7 @@
+ bv,n 0(%r3)
+ nop
+ .word 0 /* checksum (will be patched) */
+- .word PA(os_hpmc) /* address of handler */
++ .word 0 /* address of handler */
+ .word 0 /* length of handler */
+ .endm
+
+--- a/arch/parisc/kernel/traps.c
++++ b/arch/parisc/kernel/traps.c
+@@ -829,7 +829,8 @@ void __init initialize_ivt(const void *i
+ for (i = 0; i < 8; i++)
+ *ivap++ = 0;
+
+- /* Compute Checksum for HPMC handler */
++ /* Setup IVA and compute checksum for HPMC handler */
++ ivap[6] = (u32)__pa(os_hpmc);
+ length = os_hpmc_size;
+ ivap[7] = length;
+
--- /dev/null
+From 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Fri, 12 Oct 2018 22:37:46 +0200
+Subject: parisc: Fix map_pages() to not overwrite existing pte entries
+
+From: Helge Deller <deller@gmx.de>
+
+commit 3c229b3f2dd8133f61bb81d3cb018be92f4bba39 upstream.
+
+Fix a long-existing small nasty bug in the map_pages() implementation which
+leads to overwriting already written pte entries with zero, *if* map_pages() is
+called a second time with an end address which isn't aligned on a pmd boundry.
+This happens for example if we want to remap only the text segment read/write
+in order to run alternative patching on the code. Exiting the loop when we
+reach the end address fixes this.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/mm/init.c | 8 ++------
+ 1 file changed, 2 insertions(+), 6 deletions(-)
+
+--- a/arch/parisc/mm/init.c
++++ b/arch/parisc/mm/init.c
+@@ -491,12 +491,8 @@ static void __init map_pages(unsigned lo
+ pte = pte_mkhuge(pte);
+ }
+
+- if (address >= end_paddr) {
+- if (force)
+- break;
+- else
+- pte_val(pte) = 0;
+- }
++ if (address >= end_paddr)
++ break;
+
+ set_pte(pg_table, pte);
+
pcmcia-implement-clkrun-protocol-disabling-for-ricoh-bridges.patch
acpica-aml-interpreter-add-region-addresses-in-global-list-during-initialization.patch
ipmi-fix-timer-race-with-module-unload.patch
+parisc-fix-address-in-hpmc-iva.patch
+parisc-fix-map_pages-to-not-overwrite-existing-pte-entries.patch
+alsa-hda-add-mic-quirk-for-the-lenovo-g50-30-17aa-3905.patch
+alsa-ca0106-disable-izd-on-sb0570-dac-to-fix-audio-pops.patch
+x86-corruption-check-fix-panic-in-memory_corruption_check-when-boot-option-without-value-is-provided.patch
+x86-kconfig-fall-back-to-ticket-spinlocks.patch
--- /dev/null
+From ccde460b9ae5c2bd5e4742af0a7f623c2daad566 Mon Sep 17 00:00:00 2001
+From: He Zhe <zhe.he@windriver.com>
+Date: Tue, 14 Aug 2018 23:33:42 +0800
+Subject: x86/corruption-check: Fix panic in memory_corruption_check() when boot option without value is provided
+
+From: He Zhe <zhe.he@windriver.com>
+
+commit ccde460b9ae5c2bd5e4742af0a7f623c2daad566 upstream.
+
+memory_corruption_check[{_period|_size}]()'s handlers do not check input
+argument before passing it to kstrtoul() or simple_strtoull(). The argument
+would be a NULL pointer if each of the kernel parameters, without its
+value, is set in command line and thus cause the following panic.
+
+PANIC: early exception 0xe3 IP 10:ffffffff73587c22 error 0 cr2 0x0
+[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.18-rc8+ #2
+[ 0.000000] RIP: 0010:kstrtoull+0x2/0x10
+...
+[ 0.000000] Call Trace
+[ 0.000000] ? set_corruption_check+0x21/0x49
+[ 0.000000] ? do_early_param+0x4d/0x82
+[ 0.000000] ? parse_args+0x212/0x330
+[ 0.000000] ? rdinit_setup+0x26/0x26
+[ 0.000000] ? parse_early_options+0x20/0x23
+[ 0.000000] ? rdinit_setup+0x26/0x26
+[ 0.000000] ? parse_early_param+0x2d/0x39
+[ 0.000000] ? setup_arch+0x2f7/0xbf4
+[ 0.000000] ? start_kernel+0x5e/0x4c2
+[ 0.000000] ? load_ucode_bsp+0x113/0x12f
+[ 0.000000] ? secondary_startup_64+0xa5/0xb0
+
+This patch adds checks to prevent the panic.
+
+Signed-off-by: He Zhe <zhe.he@windriver.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: gregkh@linuxfoundation.org
+Cc: kstewart@linuxfoundation.org
+Cc: pombredanne@nexb.com
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1534260823-87917-1-git-send-email-zhe.he@windriver.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/check.c | 15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+--- a/arch/x86/kernel/check.c
++++ b/arch/x86/kernel/check.c
+@@ -30,6 +30,11 @@ static __init int set_corruption_check(c
+ ssize_t ret;
+ unsigned long val;
+
++ if (!arg) {
++ pr_err("memory_corruption_check config string not provided\n");
++ return -EINVAL;
++ }
++
+ ret = kstrtoul(arg, 10, &val);
+ if (ret)
+ return ret;
+@@ -44,6 +49,11 @@ static __init int set_corruption_check_p
+ ssize_t ret;
+ unsigned long val;
+
++ if (!arg) {
++ pr_err("memory_corruption_check_period config string not provided\n");
++ return -EINVAL;
++ }
++
+ ret = kstrtoul(arg, 10, &val);
+ if (ret)
+ return ret;
+@@ -58,6 +68,11 @@ static __init int set_corruption_check_s
+ char *end;
+ unsigned size;
+
++ if (!arg) {
++ pr_err("memory_corruption_check_size config string not provided\n");
++ return -EINVAL;
++ }
++
+ size = memparse(arg, &end);
+
+ if (*end == '\0')
--- /dev/null
+From wagi@monom.org Sat Nov 10 10:41:00 2018
+From: Daniel Wagner <wagi@monom.org>
+Date: Wed, 31 Oct 2018 09:14:58 +0100
+Subject: x86/kconfig: Fall back to ticket spinlocks
+To: stable@vger.kernel.org, linux-kernel@vger.kernel.org
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Daniel Wagner <daniel.wagner@siemens.com>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>
+Message-ID: <20181031081458.13996-1-wagi@monom.org>
+
+From: Daniel Wagner <daniel.wagner@siemens.com>
+
+Sebastian writes:
+
+"""
+We reproducibly observe cache line starvation on a Core2Duo E6850 (2
+cores), a i5-6400 SKL (4 cores) and on a NXP LS2044A ARM Cortex-A72 (4
+cores).
+
+The problem can be triggered with a v4.9-RT kernel by starting
+
+ cyclictest -S -p98 -m -i2000 -b 200
+
+and as "load"
+
+ stress-ng --ptrace 4
+
+The reported maximal latency is usually less than 60us. If the problem
+triggers then values around 400us, 800us or even more are reported. The
+upperlimit is the -i parameter.
+
+Reproduction with 4.9-RT is almost immediate on Core2Duo, ARM64 and SKL,
+but it took 7.5 hours to trigger on v4.14-RT on the Core2Duo.
+
+Instrumentation show always the picture:
+
+CPU0 CPU1
+=> do_syscall_64 => do_syscall_64
+=> SyS_ptrace => syscall_slow_exit_work
+=> ptrace_check_attach => ptrace_do_notify / rt_read_unlock
+=> wait_task_inactive rt_spin_lock_slowunlock()
+ -> while task_running() __rt_mutex_unlock_common()
+ / check_task_state() mark_wakeup_next_waiter()
+ | raw_spin_lock_irq(&p->pi_lock); raw_spin_lock(¤t->pi_lock);
+ | . .
+ | raw_spin_unlock_irq(&p->pi_lock); .
+ \ cpu_relax() .
+ - .
+ *IRQ* <lock acquired>
+
+In the error case we observe that the while() loop is repeated more than
+5000 times which indicates that the pi_lock can be acquired. CPU1 on the
+other side does not make progress waiting for the same lock with interrupts
+disabled.
+
+This continues until an IRQ hits CPU0. Once CPU0 starts processing the IRQ
+the other CPU is able to acquire pi_lock and the situation relaxes.
+"""
+
+This matches with the observeration for v4.4-rt on a Core2Duo E6850:
+
+CPU 0:
+
+- no progress for a very long time in rt_mutex_dequeue_pi):
+
+stress-n-1931 0d..11 5060.891219: function: __try_to_take_rt_mutex
+stress-n-1931 0d..11 5060.891219: function: rt_mutex_dequeue
+stress-n-1931 0d..21 5060.891220: function: rt_mutex_enqueue_pi
+stress-n-1931 0....2 5060.891220: signal_generate: sig=17 errno=0 code=262148 comm=stress-ng-ptrac pid=1928 grp=1 res=1
+stress-n-1931 0d..21 5060.894114: function: rt_mutex_dequeue_pi
+stress-n-1931 0d.h11 5060.894115: local_timer_entry: vector=239
+
+CPU 1:
+
+- IRQ at 5060.894114 on CPU 1 followed by the IRQ on CPU 0
+
+stress-n-1928 1....0 5060.891215: sys_enter: NR 101 (18, 78b, 0, 0, 17, 788)
+stress-n-1928 1d..11 5060.891216: function: __try_to_take_rt_mutex
+stress-n-1928 1d..21 5060.891216: function: rt_mutex_enqueue_pi
+stress-n-1928 1d..21 5060.891217: function: rt_mutex_dequeue_pi
+stress-n-1928 1....1 5060.891217: function: rt_mutex_adjust_prio
+stress-n-1928 1d..11 5060.891218: function: __rt_mutex_adjust_prio
+stress-n-1928 1d.h10 5060.894114: local_timer_entry: vector=239
+
+Thomas writes:
+
+"""
+This has nothing to do with RT. RT is merily exposing the
+problem in an observable way. The same issue happens with upstream, it's
+harder to trigger and it's harder to observe for obvious reasons.
+
+If you read through the discussions [see the links below] then you
+really see that there is an upstream issue with the x86 qrlock
+implementation and Peter has posted fixes which resolve it, both at
+the practical and the theoretical level.
+"""
+
+Backporting all qspinlock related patches is very likely to introduce
+regressions on v4.4. Therefore, the recommended solution by Peter and
+Thomas is to drop back to ticket spinlocks for v4.4.
+
+Link :https://lkml.kernel.org/r/20180921120226.6xjgr4oiho22ex75@linutronix.de
+Link: https://lkml.kernel.org/r/20180926110117.405325143@infradead.org
+Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Acked-by: Peter Zijlstra <peterz@infradead.org>
+Acked-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Daniel Wagner <daniel.wagner@siemens.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+
+Thomas suggest following plan for fixing the issues on the varous
+stable trees:
+
+ 4.4: Trivial by switching back to ticket locks.
+
+ 4.9: Decide whether bringing back ticket locks or backporting all qrlock
+ fixes. Sebastian has done the latter already and it's probably the
+ right solution
+
+ 4.14:
+ 4.18: Backporting the qrlock fixes
+
+ 4.19: Either the fix ends up in 4.19 final or it needs to be backported
+
+
+ arch/x86/Kconfig | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -41,7 +41,6 @@ config X86
+ select ARCH_USE_BUILTIN_BSWAP
+ select ARCH_USE_CMPXCHG_LOCKREF if X86_64
+ select ARCH_USE_QUEUED_RWLOCKS
+- select ARCH_USE_QUEUED_SPINLOCKS
+ select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
+ select ARCH_WANTS_DYNAMIC_TASK_STRUCT
+ select ARCH_WANT_FRAME_POINTERS
projects / thirdparty / kernel / stable-queue.git / commitdiff
