From: Sasha Levin Date: Wed, 4 Jan 2023 13:05:38 +0000 (-0500) Subject: Fixes for 5.15 X-Git-Tag: v6.1.4~64^2~3 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=3c7fab34ee19fb1a36c30fa923d93fef7baf5cbe;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.15 Signed-off-by: Sasha Levin --- diff --git a/queue-5.15/alsa-hda-realtek-apply-dual-codec-fixup-for-dell-lat.patch b/queue-5.15/alsa-hda-realtek-apply-dual-codec-fixup-for-dell-lat.patch new file mode 100644 index 00000000000..9ab3446fa49 --- /dev/null +++ b/queue-5.15/alsa-hda-realtek-apply-dual-codec-fixup-for-dell-lat.patch @@ -0,0 +1,69 @@ +From acd16c491538c3e24981be3b41fad6080b8770bc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 26 Dec 2022 19:43:03 +0800 +Subject: ALSA: hda/realtek: Apply dual codec fixup for Dell Latitude laptops + +From: Chris Chiu + +[ Upstream commit a4517c4f3423c7c448f2c359218f97c1173523a1 ] + +The Dell Latiture 3340/3440/3540 laptops with Realtek ALC3204 have +dual codecs and need the ALC1220_FIXUP_GB_DUAL_CODECS to fix the +conflicts of Master controls. The existing headset mic fixup for +Dell is also required to enable the jack sense and the headset mic. + +Introduce a new fixup to fix the dual codec and headset mic issues +for particular Dell laptops since other old Dell laptops with the +same codec configuration are already well handled by the fixup in +alc269_fallback_pin_fixup_tbl[]. + +Signed-off-by: Chris Chiu +Cc: +Link: https://lore.kernel.org/r/20221226114303.4027500-1-chris.chiu@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index f74c49987f1a..642e212278ac 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6969,6 +6969,7 @@ enum { + ALC285_FIXUP_LEGION_Y9000X_AUTOMUTE, + ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED, + ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS, ++ ALC236_FIXUP_DELL_DUAL_CODECS, + }; + + /* A special fixup for Lenovo C940 and Yoga Duet 7; +@@ -8801,6 +8802,12 @@ static const struct hda_fixup alc269_fixups[] = { + .chained = true, + .chain_id = ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, + }, ++ [ALC236_FIXUP_DELL_DUAL_CODECS] = { ++ .type = HDA_FIXUP_PINS, ++ .v.func = alc1220_fixup_gb_dual_codecs, ++ .chained = true, ++ .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ }, + }; + + static const struct snd_pci_quirk alc269_fixup_tbl[] = { +@@ -8902,6 +8909,12 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { + SND_PCI_QUIRK(0x1028, 0x0b1a, "Dell Precision 5570", ALC289_FIXUP_DUAL_SPK), + SND_PCI_QUIRK(0x1028, 0x0b37, "Dell Inspiron 16 Plus 7620 2-in-1", ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS), + SND_PCI_QUIRK(0x1028, 0x0b71, "Dell Inspiron 16 Plus 7620", ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS), ++ SND_PCI_QUIRK(0x1028, 0x0c19, "Dell Precision 3340", ALC236_FIXUP_DELL_DUAL_CODECS), ++ SND_PCI_QUIRK(0x1028, 0x0c1a, "Dell Precision 3340", ALC236_FIXUP_DELL_DUAL_CODECS), ++ SND_PCI_QUIRK(0x1028, 0x0c1b, "Dell Precision 3440", ALC236_FIXUP_DELL_DUAL_CODECS), ++ SND_PCI_QUIRK(0x1028, 0x0c1c, "Dell Precision 3540", ALC236_FIXUP_DELL_DUAL_CODECS), ++ SND_PCI_QUIRK(0x1028, 0x0c1d, "Dell Precision 3440", ALC236_FIXUP_DELL_DUAL_CODECS), ++ SND_PCI_QUIRK(0x1028, 0x0c1e, "Dell Precision 3540", ALC236_FIXUP_DELL_DUAL_CODECS), + SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), +-- +2.35.1 + diff --git a/queue-5.15/alsa-patch_realtek-fix-dell-inspiron-plus-16.patch b/queue-5.15/alsa-patch_realtek-fix-dell-inspiron-plus-16.patch new file mode 100644 index 00000000000..37dd702c83b --- /dev/null +++ b/queue-5.15/alsa-patch_realtek-fix-dell-inspiron-plus-16.patch @@ -0,0 +1,94 @@ +From 6e7497d15ae1f57d2ba80785b9964b8e1f285e62 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 5 Dec 2022 17:37:13 +0100 +Subject: ALSA: patch_realtek: Fix Dell Inspiron Plus 16 + +From: Philipp Jungkamp + +[ Upstream commit 2912cdda734d9136615ed05636d9fcbca2a7a3c5 ] + +The Dell Inspiron Plus 16, in both laptop and 2in1 form factor, has top +speakers connected on NID 0x17, which the codec reports as unconnected. +These speakers should be connected to the DAC on NID 0x03. + +Signed-off-by: Philipp Jungkamp +Link: https://lore.kernel.org/r/20221205163713.7476-1-p.jungkamp@gmx.net +Signed-off-by: Takashi Iwai +Stable-dep-of: a4517c4f3423 ("ALSA: hda/realtek: Apply dual codec fixup for Dell Latitude laptops") +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 37 +++++++++++++++++++++++++++++++++++ + 1 file changed, 37 insertions(+) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index 79c65da1b4ee..f74c49987f1a 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6709,6 +6709,34 @@ static void alc256_fixup_mic_no_presence_and_resume(struct hda_codec *codec, + } + } + ++static void alc295_fixup_dell_inspiron_top_speakers(struct hda_codec *codec, ++ const struct hda_fixup *fix, int action) ++{ ++ static const struct hda_pintbl pincfgs[] = { ++ { 0x14, 0x90170151 }, ++ { 0x17, 0x90170150 }, ++ { } ++ }; ++ static const hda_nid_t conn[] = { 0x02, 0x03 }; ++ static const hda_nid_t preferred_pairs[] = { ++ 0x14, 0x02, ++ 0x17, 0x03, ++ 0x21, 0x02, ++ 0 ++ }; ++ struct alc_spec *spec = codec->spec; ++ ++ alc_fixup_no_shutup(codec, fix, action); ++ ++ switch (action) { ++ case HDA_FIXUP_ACT_PRE_PROBE: ++ snd_hda_apply_pincfgs(codec, pincfgs); ++ snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn); ++ spec->gen.preferred_dacs = preferred_pairs; ++ break; ++ } ++} ++ + enum { + ALC269_FIXUP_GPIO2, + ALC269_FIXUP_SONY_VAIO, +@@ -6940,6 +6968,7 @@ enum { + ALC285_FIXUP_LEGION_Y9000X_SPEAKERS, + ALC285_FIXUP_LEGION_Y9000X_AUTOMUTE, + ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED, ++ ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS, + }; + + /* A special fixup for Lenovo C940 and Yoga Duet 7; +@@ -8766,6 +8795,12 @@ static const struct hda_fixup alc269_fixups[] = { + .chained = true, + .chain_id = ALC285_FIXUP_HP_MUTE_LED, + }, ++ [ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS] = { ++ .type = HDA_FIXUP_FUNC, ++ .v.func = alc295_fixup_dell_inspiron_top_speakers, ++ .chained = true, ++ .chain_id = ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, ++ }, + }; + + static const struct snd_pci_quirk alc269_fixup_tbl[] = { +@@ -8865,6 +8900,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { + SND_PCI_QUIRK(0x1028, 0x0a9e, "Dell Latitude 5430", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x0b19, "Dell XPS 15 9520", ALC289_FIXUP_DUAL_SPK), + SND_PCI_QUIRK(0x1028, 0x0b1a, "Dell Precision 5570", ALC289_FIXUP_DUAL_SPK), ++ SND_PCI_QUIRK(0x1028, 0x0b37, "Dell Inspiron 16 Plus 7620 2-in-1", ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS), ++ SND_PCI_QUIRK(0x1028, 0x0b71, "Dell Inspiron 16 Plus 7620", ALC295_FIXUP_DELL_INSPIRON_TOP_SPEAKERS), + SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2), +-- +2.35.1 + diff --git a/queue-5.15/rtmutex-add-acquire-semantics-for-rtmutex-lock-acqui.patch b/queue-5.15/rtmutex-add-acquire-semantics-for-rtmutex-lock-acqui.patch new file mode 100644 index 00000000000..49d8697242a --- /dev/null +++ b/queue-5.15/rtmutex-add-acquire-semantics-for-rtmutex-lock-acqui.patch @@ -0,0 +1,227 @@ +From 008604345f50eeebd31e85e7b1d1be2a9ec5f5e8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 2 Dec 2022 10:02:23 +0000 +Subject: rtmutex: Add acquire semantics for rtmutex lock acquisition slow path + +From: Mel Gorman + +[ Upstream commit 1c0908d8e441631f5b8ba433523cf39339ee2ba0 ] + +Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench +on XFS on arm64. + + kernel BUG at fs/inode.c:625! + Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP + CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 + pc : clear_inode+0xa0/0xc0 + lr : clear_inode+0x38/0xc0 + Call trace: + clear_inode+0xa0/0xc0 + evict+0x160/0x180 + iput+0x154/0x240 + do_unlinkat+0x184/0x300 + __arm64_sys_unlinkat+0x48/0xc0 + el0_svc_common.constprop.4+0xe4/0x2c0 + do_el0_svc+0xac/0x100 + el0_svc+0x78/0x200 + el0t_64_sync_handler+0x9c/0xc0 + el0t_64_sync+0x19c/0x1a0 + +It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this +is likely a bug that existed forever and only became visible when ARM +support was added to preempt-rt. The same problem does not occur on x86-64 +and he also reported that converting sb->s_inode_wblist_lock to +raw_spinlock_t makes the problem disappear indicating that the RT spinlock +variant is the problem. + +Which in turn means that RT mutexes on ARM64 and any other weakly ordered +architecture are affected by this independent of RT. + +Will Deacon observed: + + "I'd be more inclined to be suspicious of the slowpath tbh, as we need to + make sure that we have acquire semantics on all paths where the lock can + be taken. Looking at the rtmutex code, this really isn't obvious to me + -- for example, try_to_take_rt_mutex() appears to be able to return via + the 'takeit' label without acquire semantics and it looks like we might + be relying on the caller's subsequent _unlock_ of the wait_lock for + ordering, but that will give us release semantics which aren't correct." + +Sebastian Andrzej Siewior prototyped a fix that does work based on that +comment but it was a little bit overkill and added some fences that should +not be necessary. + +The lock owner is updated with an IRQ-safe raw spinlock held, but the +spin_unlock does not provide acquire semantics which are needed when +acquiring a mutex. + +Adds the necessary acquire semantics for lock owner updates in the slow path +acquisition and the waiter bit logic. + +It successfully completed 10 iterations of the dbench workload while the +vanilla kernel fails on the first iteration. + +[ bigeasy@linutronix.de: Initial prototype fix ] + +Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") +Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") +Reported-by: Jan Kara +Signed-off-by: Mel Gorman +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.net +Signed-off-by: Sasha Levin +--- + kernel/locking/rtmutex.c | 56 ++++++++++++++++++++++++++++++------ + kernel/locking/rtmutex_api.c | 6 ++-- + 2 files changed, 50 insertions(+), 12 deletions(-) + +diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c +index ea5a701ab240..3060cb6bd504 100644 +--- a/kernel/locking/rtmutex.c ++++ b/kernel/locking/rtmutex.c +@@ -87,15 +87,31 @@ static inline int __ww_mutex_check_kill(struct rt_mutex *lock, + * set this bit before looking at the lock. + */ + +-static __always_inline void +-rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) ++static __always_inline struct task_struct * ++rt_mutex_owner_encode(struct rt_mutex_base *lock, struct task_struct *owner) + { + unsigned long val = (unsigned long)owner; + + if (rt_mutex_has_waiters(lock)) + val |= RT_MUTEX_HAS_WAITERS; + +- WRITE_ONCE(lock->owner, (struct task_struct *)val); ++ return (struct task_struct *)val; ++} ++ ++static __always_inline void ++rt_mutex_set_owner(struct rt_mutex_base *lock, struct task_struct *owner) ++{ ++ /* ++ * lock->wait_lock is held but explicit acquire semantics are needed ++ * for a new lock owner so WRITE_ONCE is insufficient. ++ */ ++ xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); ++} ++ ++static __always_inline void rt_mutex_clear_owner(struct rt_mutex_base *lock) ++{ ++ /* lock->wait_lock is held so the unlock provides release semantics. */ ++ WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); + } + + static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) +@@ -104,7 +120,8 @@ static __always_inline void clear_rt_mutex_waiters(struct rt_mutex_base *lock) + ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); + } + +-static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) ++static __always_inline void ++fixup_rt_mutex_waiters(struct rt_mutex_base *lock, bool acquire_lock) + { + unsigned long owner, *p = (unsigned long *) &lock->owner; + +@@ -170,8 +187,21 @@ static __always_inline void fixup_rt_mutex_waiters(struct rt_mutex_base *lock) + * still set. + */ + owner = READ_ONCE(*p); +- if (owner & RT_MUTEX_HAS_WAITERS) +- WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); ++ if (owner & RT_MUTEX_HAS_WAITERS) { ++ /* ++ * See rt_mutex_set_owner() and rt_mutex_clear_owner() on ++ * why xchg_acquire() is used for updating owner for ++ * locking and WRITE_ONCE() for unlocking. ++ * ++ * WRITE_ONCE() would work for the acquire case too, but ++ * in case that the lock acquisition failed it might ++ * force other lockers into the slow path unnecessarily. ++ */ ++ if (acquire_lock) ++ xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); ++ else ++ WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); ++ } + } + + /* +@@ -206,6 +236,13 @@ static __always_inline void mark_rt_mutex_waiters(struct rt_mutex_base *lock) + owner = *p; + } while (cmpxchg_relaxed(p, owner, + owner | RT_MUTEX_HAS_WAITERS) != owner); ++ ++ /* ++ * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE ++ * operations in the event of contention. Ensure the successful ++ * cmpxchg is visible. ++ */ ++ smp_mb__after_atomic(); + } + + /* +@@ -1231,7 +1268,7 @@ static int __sched __rt_mutex_slowtrylock(struct rt_mutex_base *lock) + * try_to_take_rt_mutex() sets the lock waiters bit + * unconditionally. Clean this up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + + return ret; + } +@@ -1591,7 +1628,8 @@ static int __sched __rt_mutex_slowlock(struct rt_mutex_base *lock, + * try_to_take_rt_mutex() sets the waiter bit + * unconditionally. We might have to fix that up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); ++ + return ret; + } + +@@ -1701,7 +1739,7 @@ static void __sched rtlock_slowlock_locked(struct rt_mutex_base *lock) + * try_to_take_rt_mutex() sets the waiter bit unconditionally. + * We might have to fix that up: + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + debug_rt_mutex_free_waiter(&waiter); + } + +diff --git a/kernel/locking/rtmutex_api.c b/kernel/locking/rtmutex_api.c +index 5c9299aaabae..a461be2f873d 100644 +--- a/kernel/locking/rtmutex_api.c ++++ b/kernel/locking/rtmutex_api.c +@@ -245,7 +245,7 @@ void __sched rt_mutex_init_proxy_locked(struct rt_mutex_base *lock, + void __sched rt_mutex_proxy_unlock(struct rt_mutex_base *lock) + { + debug_rt_mutex_proxy_unlock(lock); +- rt_mutex_set_owner(lock, NULL); ++ rt_mutex_clear_owner(lock); + } + + /** +@@ -360,7 +360,7 @@ int __sched rt_mutex_wait_proxy_lock(struct rt_mutex_base *lock, + * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might + * have to fix that up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, true); + raw_spin_unlock_irq(&lock->wait_lock); + + return ret; +@@ -416,7 +416,7 @@ bool __sched rt_mutex_cleanup_proxy_lock(struct rt_mutex_base *lock, + * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might + * have to fix that up. + */ +- fixup_rt_mutex_waiters(lock); ++ fixup_rt_mutex_waiters(lock, false); + + raw_spin_unlock_irq(&lock->wait_lock); + +-- +2.35.1 + diff --git a/queue-5.15/series b/queue-5.15/series index 136f26ad4be..e1060d08e33 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -57,3 +57,6 @@ asoc-soundwire-dai-expand-stream-concept-beyond-soundwire.patch rcu-tasks-simplify-trc_read_check_handler-atomic-operations.patch net-af_packet-add-vlan-support-for-af_packet-sock_raw-gso.patch net-af_packet-make-sure-to-pull-mac-header.patch +rtmutex-add-acquire-semantics-for-rtmutex-lock-acqui.patch +alsa-patch_realtek-fix-dell-inspiron-plus-16.patch +alsa-hda-realtek-apply-dual-codec-fixup-for-dell-lat.patch