--- /dev/null
+From 2da31ea2a085cd189857f2db0f7b78d0162db87a Mon Sep 17 00:00:00 2001
+From: Paul Menzel <pmenzel@molgen.mpg.de>
+Date: Tue, 18 Mar 2025 17:09:02 +0100
+Subject: ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Paul Menzel <pmenzel@molgen.mpg.de>
+
+commit 2da31ea2a085cd189857f2db0f7b78d0162db87a upstream.
+
+Like the ASUS Vivobook X1504VAP and Vivobook X1704VAP, the ASUS Vivobook 14
+X1404VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which
+the kernel overrides to EdgeHigh breaking the keyboard.
+
+ $ sudo dmidecode
+ […]
+ System Information
+ Manufacturer: ASUSTeK COMPUTER INC.
+ Product Name: ASUS Vivobook 14 X1404VAP_X1404VA
+ […]
+ $ grep -A 30 PS2K dsdt.dsl | grep IRQ -A 1
+ IRQ (Level, ActiveLow, Exclusive, )
+ {1}
+
+Add the X1404VAP to the irq1_level_low_skip_override[] quirk table to fix
+this.
+
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Tested-by: Anton Shyndin <mrcold.il@gmail.com>
+Link: https://patch.msgid.link/20250318160903.77107-1-pmenzel@molgen.mpg.de
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/resource.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -443,6 +443,13 @@ static const struct dmi_system_id asus_l
+ },
+ },
+ {
++ /* Asus Vivobook X1404VAP */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_BOARD_NAME, "X1404VAP"),
++ },
++ },
++ {
+ /* Asus Vivobook X1504VAP */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
arcnet-add-null-check-in-com20020pci_probe.patch
can-flexcan-only-change-can-state-when-link-up-in-sy.patch
ntb_perf-delete-duplicate-dmaengine_unmap_put-call-in-perf_copy_chunk.patch
+x86-tsc-always-save-restore-tsc-sched_clock-on-suspend-resume.patch
+x86-mm-fix-flush_tlb_range-when-used-for-zapping-normal-pmds.patch
+acpi-resource-skip-irq-override-on-asus-vivobook-14-x1404vap.patch
--- /dev/null
+From 3ef938c3503563bfc2ac15083557f880d29c2e64 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Fri, 3 Jan 2025 19:39:38 +0100
+Subject: x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs
+
+From: Jann Horn <jannh@google.com>
+
+commit 3ef938c3503563bfc2ac15083557f880d29c2e64 upstream.
+
+On the following path, flush_tlb_range() can be used for zapping normal
+PMD entries (PMD entries that point to page tables) together with the PTE
+entries in the pointed-to page table:
+
+ collapse_pte_mapped_thp
+ pmdp_collapse_flush
+ flush_tlb_range
+
+The arm64 version of flush_tlb_range() has a comment describing that it can
+be used for page table removal, and does not use any last-level
+invalidation optimizations. Fix the X86 version by making it behave the
+same way.
+
+Currently, X86 only uses this information for the following two purposes,
+which I think means the issue doesn't have much impact:
+
+ - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be
+ IPI'd to avoid issues with speculative page table walks.
+ - In Hyper-V TLB paravirtualization, again for lazy TLB stuff.
+
+The patch "x86/mm: only invalidate final translations with INVLPGB" which
+is currently under review (see
+<https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>)
+would probably be making the impact of this a lot worse.
+
+Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range")
+Signed-off-by: Jann Horn <jannh@google.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20250103-x86-collapse-flush-fix-v1-1-3c521856cfa6@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/tlbflush.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/tlbflush.h
++++ b/arch/x86/include/asm/tlbflush.h
+@@ -572,7 +572,7 @@ struct flush_tlb_info {
+ flush_tlb_mm_range((vma)->vm_mm, start, end, \
+ ((vma)->vm_flags & VM_HUGETLB) \
+ ? huge_page_shift(hstate_vma(vma)) \
+- : PAGE_SHIFT, false)
++ : PAGE_SHIFT, true)
+
+ extern void flush_tlb_all(void);
+ extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
--- /dev/null
+From d90c9de9de2f1712df56de6e4f7d6982d358cabe Mon Sep 17 00:00:00 2001
+From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
+Date: Sat, 15 Feb 2025 17:58:16 -0300
+Subject: x86/tsc: Always save/restore TSC sched_clock() on suspend/resume
+
+From: Guilherme G. Piccoli <gpiccoli@igalia.com>
+
+commit d90c9de9de2f1712df56de6e4f7d6982d358cabe upstream.
+
+TSC could be reset in deep ACPI sleep states, even with invariant TSC.
+
+That's the reason we have sched_clock() save/restore functions, to deal
+with this situation. But what happens is that such functions are guarded
+with a check for the stability of sched_clock - if not considered stable,
+the save/restore routines aren't executed.
+
+On top of that, we have a clear comment in native_sched_clock() saying
+that *even* with TSC unstable, we continue using TSC for sched_clock due
+to its speed.
+
+In other words, if we have a situation of TSC getting detected as unstable,
+it marks the sched_clock as unstable as well, so subsequent S3 sleep cycles
+could bring bogus sched_clock values due to the lack of the save/restore
+mechanism, causing warnings like this:
+
+ [22.954918] ------------[ cut here ]------------
+ [22.954923] Delta way too big! 18446743750843854390 ts=18446744072977390405 before=322133536015 after=322133536015 write stamp=18446744072977390405
+ [22.954923] If you just came from a suspend/resume,
+ [22.954923] please switch to the trace global clock:
+ [22.954923] echo global > /sys/kernel/tracing/trace_clock
+ [22.954923] or add trace_clock=global to the kernel command line
+ [22.954937] WARNING: CPU: 2 PID: 5728 at kernel/trace/ring_buffer.c:2890 rb_add_timestamp+0x193/0x1c0
+
+Notice that the above was reproduced even with "trace_clock=global".
+
+The fix for that is to _always_ save/restore the sched_clock on suspend
+cycle _if TSC is used_ as sched_clock - only if we fallback to jiffies
+the sched_clock_stable() check becomes relevant to save/restore the
+sched_clock.
+
+Debugged-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
+Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: stable@vger.kernel.org
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Link: https://lore.kernel.org/r/20250215210314.351480-1-gpiccoli@igalia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/tsc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/tsc.c
++++ b/arch/x86/kernel/tsc.c
+@@ -912,7 +912,7 @@ static unsigned long long cyc2ns_suspend
+
+ void tsc_save_sched_clock_state(void)
+ {
+- if (!sched_clock_stable())
++ if (!static_branch_likely(&__use_tsc) && !sched_clock_stable())
+ return;
+
+ cyc2ns_suspend = sched_clock();
+@@ -932,7 +932,7 @@ void tsc_restore_sched_clock_state(void)
+ unsigned long flags;
+ int cpu;
+
+- if (!sched_clock_stable())
++ if (!static_branch_likely(&__use_tsc) && !sched_clock_stable())
+ return;
+
+ local_irq_save(flags);
projects / thirdparty / kernel / stable-queue.git / commitdiff
