kernel/linux.git, branch v6.14.8

Linux 6.14.8

2025-05-22T12:31:58+00:00

Link: https://lore.kernel.org/r/20250520125810.535475500@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Luna Jernberg Tested-by: Florian Fainelli Tested-by: Miguel Ojeda Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Markus Reichelt Tested-by: Peter Schneider Tested-by: Mark Brown Tested-by: Hardik Garg Signed-off-by: Greg Kroah-Hartman

phy: tegra: xusb: remove a stray unlock

2025-05-22T12:31:58+00:00

commit 83c178470e0bf690d34c8c08440f2421b82e881c upstream. We used to take a lock in tegra186_utmi_bias_pad_power_on() but now we have moved the lock into the caller. Unfortunately, when we moved the lock this unlock was left behind and it results in a double unlock. Delete it now. Fixes: b47158fb4295 ("phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking") Signed-off-by: Dan Carpenter Reviewed-by: Jon Hunter Link: https://lore.kernel.org/r/aAjmR6To4EnvRl4G@stanley.mountain Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman

perf tools: Fix build error for LoongArch

2025-05-22T12:31:58+00:00

There exists the following error when building perf tools on LoongArch: CC util/syscalltbl.o In file included from util/syscalltbl.c:16: tools/perf/arch/loongarch/include/syscall_table.h:2:10: fatal error: asm/syscall_table_64.h: No such file or directory 2 | #include | ^~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. This is because the generated syscall header is syscalls_64.h rather than syscall_table_64.h. The above problem was introduced from v6.14, then the header syscall_table.h has been removed from mainline tree in commit af472d3c4454 ("perf syscalltbl: Remove syscall_table.h"), just fix it only for the linux-6.14.y branch of stable tree. By the way, no need to fix the mainline tree and there is no upstream git id for this patch. How to reproduce: git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git cd linux && git checkout origin/linux-6.14.y make JOBS=1 -C tools/perf Fixes: fa70857a27e5 ("perf tools loongarch: Use syscall table") Signed-off-by: Tiezhu Yang Signed-off-by: Greg Kroah-Hartman

mm/page_alloc: fix race condition in unaccepted memory handling

2025-05-22T12:31:58+00:00

commit fefc075182275057ce607effaa3daa9e6e3bdc73 upstream. The page allocator tracks the number of zones that have unaccepted memory using static_branch_enc/dec() and uses that static branch in hot paths to determine if it needs to deal with unaccepted memory. Borislav and Thomas pointed out that the tracking is racy: operations on static_branch are not serialized against adding/removing unaccepted pages to/from the zone. Sanity checks inside static_branch machinery detects it: WARNING: CPU: 0 PID: 10 at kernel/jump_label.c:276 __static_key_slow_dec_cpuslocked+0x8e/0xa0 The comment around the WARN() explains the problem: /* * Warn about the '-1' case though; since that means a * decrement is concurrent with a first (0->1) increment. IOW * people are trying to disable something that wasn't yet fully * enabled. This suggests an ordering problem on the user side. */ The effect of this static_branch optimization is only visible on microbenchmark. Instead of adding more complexity around it, remove it altogether. Link: https://lkml.kernel.org/r/20250506133207.1009676-1-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov Fixes: dcdfdd40fa82 ("mm: Add support for unaccepted memory") Link: https://lore.kernel.org/all/20250506092445.GBaBnVXXyvnazly6iF@fat_crate.local Reported-by: Borislav Petkov Tested-by: Borislav Petkov (AMD) Reported-by: Thomas Gleixner Cc: Vlastimil Babka Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Brendan Jackman Cc: Johannes Weiner Cc: [6.5+] Signed-off-by: Andrew Morton Signed-off-by: Kirill A. Shutemov Signed-off-by: Greg Kroah-Hartman

drm/xe/gsc: do not flush the GSC worker from the reset path

2025-05-22T12:31:57+00:00

commit 03552d8ac0afcc080c339faa0b726e2c0e9361cb upstream. The workqueue used for the reset worker is marked as WQ_MEM_RECLAIM, while the GSC one isn't (and can't be as we need to do memory allocations in the gsc worker). Therefore, we can't flush the latter from the former. The reason why we had such a flush was to avoid interrupting either the GSC FW load or in progress GSC proxy operations. GSC proxy operations fall into 2 categories: 1) GSC proxy init: this only happens once immediately after GSC FW load and does not support being interrupted. The only way to recover from an interruption of the proxy init is to do an FLR and re-load the GSC. 2) GSC proxy request: this can happen in response to a request that the driver sends to the GSC. If this is interrupted, the GSC FW will timeout and the driver request will be failed, but overall the GSC will keep working fine. Flushing the work allowed us to avoid interruption in both cases (unless the hang came from the GSC engine itself, in which case we're toast anyway). However, a failure on a proxy request is tolerable if we're in a scenario where we're triggering a GT reset (i.e., something is already gone pretty wrong), so what we really need to avoid is interrupting the init flow, which we can do by polling on the register that reports when the proxy init is complete (as that ensure us that all the load and init operations have been completed). Note that during suspend we still want to do a flush of the worker to make sure it completes any operations involving the HW before the power is cut. v2: fix spelling in commit msg, rename waiter function (Julia) Fixes: dd0e89e5edc2 ("drm/xe/gsc: GSC FW load") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4830 Signed-off-by: Daniele Ceraolo Spurio Cc: John Harrison Cc: Alan Previn Cc: # v6.8+ Reviewed-by: Julia Filipchuk Link: https://lore.kernel.org/r/20250502155104.2201469-1-daniele.ceraolospurio@intel.com (cherry picked from commit 12370bfcc4f0bdf70279ec5b570eb298963422b5) Signed-off-by: Lucas De Marchi Signed-off-by: Greg Kroah-Hartman

accel/ivpu: Flush pending jobs of device's workqueues

2025-05-22T12:31:57+00:00

commit 683e9fa1c885a0cffbc10b459a7eee9df92af1c1 upstream. Use flush_work() instead of cancel_work_sync() for driver IRQ workqueues to guarantee that remaining pending work will be handled. This resolves two issues that were encountered where a driver was left in an incorrect state as the bottom-half was canceled: 1. Cancelling context-abort of a job that is still executing and is causing translation faults which is going to cause additional TDRs 2. Cancelling bottom-half of a DCT (duty-cycle throttling) request which will cause a device to not be adjusted to an external frequency request. Fixes: bc3e5f48b7ee ("accel/ivpu: Use workqueue for IRQ handling") Signed-off-by: Maciej Falkowski Reviewed-by: Lizhi Hou Reviewed-by: Jeff Hugo Signed-off-by: Jacek Lawrynowicz Link: https://lore.kernel.org/r/20250401155755.4049156-1-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman

accel/ivpu: Fix missing MMU events if file_priv is unbound

2025-05-22T12:31:57+00:00

commit 2f5bbea1807a064a1e4c1b385c8cea4f37bb4b17 upstream. Move the ivpu_mmu_discard_events() function to the common portion of the abort work function. This ensures it is called only once, even if there are no faulty contexts in context_xa, to guarantee that MMU events are discarded and new events are not missed. Reviewed-by: Jacek Lawrynowicz Signed-off-by: Karol Wachowski Reviewed-by: Jeffrey Hugo Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250129125636.1047413-4-jacek.lawrynowicz@linux.intel.com Signed-off-by: Greg Kroah-Hartman

accel/ivpu: Fix missing MMU events from reserved SSID

2025-05-22T12:31:57+00:00

commit 353b8f48390d36b39276ff6af61464ec64cd4d5c upstream. Generate recovery when fault from reserved context is detected. Add Abort (A) bit to reserved (1) SSID to ensure NPU also receives a fault. There is no way to create a file_priv with reserved SSID but it is still possible to receive MMU faults from that SSID as it is a default NPU HW setting. Such situation will occur if FW freed context related resources but still performed access to DRAM. Signed-off-by: Karol Wachowski Signed-off-by: Maciej Falkowski Reviewed-by: Jacek Lawrynowicz Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250107173238.381120-9-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman

accel/ivpu: Move parts of MMU event IRQ handling to thread handler

2025-05-22T12:31:57+00:00

commit 4480912f3f8b8a1fbb5ae12c5c547fd094ec4197 upstream. To prevent looping infinitely in MMU event handler we stop generating new events by removing 'R' (record) bit from context descriptor, but to ensure this change has effect KMD has to perform configuration invalidation followed by sync command. Because of that move parts of the interrupt handler that can take longer to a thread not to block in interrupt handler for too long. This includes: * disabling event queue for the time KMD updates MMU event queue consumer to ensure proper synchronization between MMU and KMD * removal of 'R' (record) bit from context descriptor to ensure no more faults are recorded until that context is destroyed Signed-off-by: Karol Wachowski Signed-off-by: Maciej Falkowski Reviewed-by: Jacek Lawrynowicz Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250107173238.381120-8-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman

accel/ivpu: Dump only first MMU fault from single context

2025-05-22T12:31:57+00:00

commit 0240fa18d247c99a1967f2fed025296a89a1c5f5 upstream. Stop dumping consecutive faults from an already faulty context immediately, instead of waiting for the context abort thread handler (IRQ handler bottom half) to abort currently executing jobs. Remove 'R' (record events) bit from context descriptor of a faulty context to prevent future faults generation. This change speeds up the IRQ handler by eliminating the need to print the fault content repeatedly. Additionally, it prevents flooding dmesg with errors, which was occurring due to the delay in the bottom half of the handler stopping fault-generating jobs. Signed-off-by: Karol Wachowski Signed-off-by: Maciej Falkowski Reviewed-by: Jacek Lawrynowicz Signed-off-by: Jacek Lawrynowicz Link: https://patchwork.freedesktop.org/patch/msgid/20250107173238.381120-7-maciej.falkowski@linux.intel.com Signed-off-by: Greg Kroah-Hartman