summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-03-29pwm: th1520: fix `CLIPPY=1` warningMiguel Ojeda
The Rust kernel code should be kept `CLIPPY=1`-clean [1]. Clippy reports: error: this pattern reimplements `Option::unwrap_or` --> drivers/pwm/pwm_th1520.rs:64:5 | 64 | / (match ns.checked_mul(rate_hz) { 65 | | Some(product) => product, 66 | | None => u64::MAX, 67 | | }) / NSEC_PER_SEC_U64 | |______^ help: replace with: `ns.checked_mul(rate_hz).unwrap_or(u64::MAX)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.92.0/index.html#manual_unwrap_or = note: `-D clippy::manual-unwrap-or` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_unwrap_or)]` Applying the suggestion then triggers: error: manual saturating arithmetic --> drivers/pwm/pwm_th1520.rs:64:5 | 64 | ns.checked_mul(rate_hz).unwrap_or(u64::MAX) / NSEC_PER_SEC_U64 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using `saturating_mul`: `ns.saturating_mul(rate_hz)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.92.0/index.html#manual_saturating_arithmetic = note: `-D clippy::manual-saturating-arithmetic` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_saturating_arithmetic)]` Thus fix it by using saturating arithmetic, which simplifies the code as well. Link: https://rust-for-linux.com/contributing#submit-checklist-addendum [1] Fixes: e03724aac758 ("pwm: Add Rust driver for T-HEAD TH1520 SoC") Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20260121183719.71659-1-ojeda@kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-03-28Merge tag 'for-7.0-rc5-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "A few more fixes. There's one that stands out in size as it fixes an edge case in fsync. - fix issue on fsync where file with zero size appears as a non-zero after log replay - in zlib compression, handle a crash when data alignment causes folio reference issues - fix possible crash with enabled tracepoints on a overlayfs mount - handle device stats update error - on zoned filesystems, fix kobject leak on sub-block groups - fix super block offset in an error message in validation" * tag 'for-7.0-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix lost error when running device stats on multiple devices fs btrfs: tracepoints: get correct superblock from dentry in event btrfs_sync_file() btrfs: zlib: handle page aligned compressed size correctly btrfs: fix leak of kobject name for sub-group space_info btrfs: fix zero size inode with non-zero size after log replay btrfs: fix super block offset in error message in btrfs_validate_super()
2026-03-28rust: move `static_assert` into `build_assert`Gary Guo
Conceptually, `static_assert` is also a build-time assertion that occurs earlier in the pipeline. Consolidate the implementation so that we can use this as the canonical place to add more useful build-time assertions. Reviewed-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260319121653.2975748-2-gary@kernel.org [ Used kernel vertical style. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-28Merge tag 'mm-hotfixes-stable-2026-03-28-10-45' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "10 hotfixes. 8 are cc:stable. 9 are for MM. There's a 3-patch series of DAMON fixes from Josh Law and SeongJae Park. The rest are singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-03-28-10-45' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/mseal: update VMA end correctly on merge bug: avoid format attribute warning for clang as well mm/pagewalk: fix race between concurrent split and refault mm/memory: fix PMD/PUD checks in follow_pfnmap_start() mm/damon/sysfs: check contexts->nr in repeat_call_fn mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0] mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure mm/swap: fix swap cache memcg accounting MAINTAINERS, mailmap: update email address for Harry Yoo mm/huge_memory: fix folio isn't locked in softleaf_to_folio()
2026-03-28x86/sev: Create snp_prepare()Tycho Andersen (AMD)
In preparation for delayed SNP initialization, create a function snp_prepare() that does the necessary architecture setup. Export this function for the ccp module to allow it to do the setup as necessary. Introduce a cpu_read_lock/unlock() wrapper around the MFDM and SNP enable. While CPU hotplug is not supported, this makes sure that the bit setting happens on the same set of CPUs in both cases. This improvement was suggested by Sashiko: https://sashiko.dev/#/patchset/20260324161301.1353976-1-tycho%40kernel.org Also move {mfd,snp}_enable() out of the __init section, since these will be called later. Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260326161110.1764303-3-tycho@kernel.org
2026-03-28x86/sev: Create a function to clear/zero the RMPTom Lendacky
In preparation for delayed SNP initialization and disablement on shutdown, create a function, clear_rmp(), that clears the RMP bookkeeping area and the RMP entries. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260324161301.1353976-2-tycho@kernel.org
2026-03-28MAINTAINERS: drop outdated I2C websiteWolfram Sang
As stated on the website: "This wiki has been archived and the content is no longer updated." No need to reference it. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-03-28tracing: Remove spurious default precision from show_event_trigger/filter ↵David Laight
formats Change 2d8b7f9bf8e6e ("tracing: Have show_event_trigger/filter format a bit more in columns") added space padding to align the output. However it used ("%*.s", len, "") which requests the default precision. It doesn't matter here whether the userspace default (0) or kernel default (no precision) is used, but the format should be "%*s". Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://patch.msgid.link/20260326201824.3919-1-david.laight.linux@gmail.com Signed-off-by: David Laight <david.laight.linux@gmail.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-28cpufreq: Use trace_call__##name() at guarded tracepoint call sitesVineeth Pillai (Google)
Replace trace_foo() with the new trace_call__foo() at sites already guarded by trace_foo_enabled(), avoiding a redundant static_branch_unlikely() re-evaluation inside the tracepoint. trace_call__foo() calls the tracepoint callbacks directly without utilizing the static branch again. Cc: Huang Rui <ray.huang@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Perry Yuan <perry.yuan@amd.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Len Brown <lenb@kernel.org> Link: https://patch.msgid.link/20260323160052.17528-7-vineeth@bitbyteword.org Suggested-by: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Vineeth Pillai (Google) <vineeth@bitbyteword.org> Assisted-by: Claude:claude-sonnet-4-6 Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> # cpufreq core Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-28KVM: arm64: Don't pass host_debug_state to BRBE world-switch routinesWill Deacon
Now that the SPE and BRBE nVHE world-switch routines operate on the host_debug_state directly, tweak the BRBE code to do the same for consistency. This is purely cosmetic. Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@kernel.org> Cc: James Clark <james.clark@linaro.org> Cc: Leo Yan <leo.yan@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Link: https://patch.msgid.link/20260327130047.21065-4-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Disable SPE Profiling Buffer when running in guest contextWill Deacon
The nVHE world-switch code relies on zeroing PMSCR_EL1 to disable profiling data generation in guest context when SPE is in use by the host. Unfortunately, this may leave PMBLIMITR_EL1.E set and consequently we can end up running in guest/hypervisor context with the Profiling Buffer enabled. The current "known issues" document for Rev M.a of the Arm ARM states that this can lead to speculative, out-of-context translations: | 2.18 D23136: | | When the Profiling Buffer is enabled, profiling is not stopped, and | Discard mode is not enabled, the Statistical Profiling Unit might | cause speculative translations for the owning translation regime, | including when the owning translation regime is out-of-context. In a similar fashion to TRBE, ensure that the Profiling Buffer is disabled during the nVHE world switch before we start messing with the stage-2 MMU and trap configuration. Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@kernel.org> Cc: James Clark <james.clark@linaro.org> Cc: Leo Yan <leo.yan@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com> Reviewed-by: Fuad Tabba <tabba@google.com> Tested-by: Alexandru Elisei <alexandru.elisei@arm.com> Tested-by: Fuad Tabba <tabba@google.com> Fixes: f85279b4bd48 ("arm64: KVM: Save/restore the host SPE state when entering/leaving a VM") Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260327130047.21065-3-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest contextWill Deacon
The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace generation in guest context when self-hosted TRBE is in use by the host. Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but per R_YCHKJ the Trace Buffer Unit will still be enabled if TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the Trace Buffer Unit can perform address translation for the "owning exception level" even when it is out of context. Consequently, we can end up in a state where TRBE performs speculative page-table walks for a host VA/IPA in guest/hypervisor context depending on the value of MDCR_EL2.E2TB, which changes over world-switch. The potential result appears to be a heady mixture of SErrors, data corruption and hardware lockups. Extend the TRBE world-switch code to clear TRBLIMITR_EL1.E after draining the buffer, restoring the register on return to the host. This unfortunately means we need to tackle CPU errata #2064142 and #2038923 which add additional synchronisation requirements around manipulations of the limit register. Hopefully this doesn't need to be fast. Cc: Marc Zyngier <maz@kernel.org> Cc: Oliver Upton <oupton@kernel.org> Cc: James Clark <james.clark@linaro.org> Cc: Leo Yan <leo.yan@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Fuad Tabba <tabba@google.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Tested-by: Leo Yan <leo.yan@arm.com> Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Fuad Tabba <tabba@google.com> Fixes: a1319260bf62 ("arm64: KVM: Enable access to TRBE support for host") Signed-off-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20260327130047.21065-2-will@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28Merge tag 'trace-v7.0-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix potential deadlock in osnoise and hotplug The interface_lock can be called by a osnoise thread and the CPU shutdown logic of osnoise can wait for this thread to finish. But cpus_read_lock() can also be taken while holding the interface_lock. This produces a circular lock dependency and can cause a deadlock. Swap the ordering of cpus_read_lock() and the interface_lock to have interface_lock taken within the cpus_read_lock() context to prevent this circular dependency. - Fix freeing of event triggers in early boot up If the same trigger is added on the kernel command line, the second one will fail to be applied and the trigger created will be freed. This calls into the deferred logic and creates a kernel thread to do the freeing. But the command line logic is called before kernel threads can be created and this leads to a NULL pointer dereference. Delay freeing event triggers until late init. * tag 'trace-v7.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Drain deferred trigger frees if kthread creation fails tracing: Fix potential deadlock in cpu hotplug with osnoise
2026-03-28Merge tag 's390-7.0-6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Add array_index_nospec() to syscall dispatch table lookup to prevent limited speculative out-of-bounds access with user-controlled syscall number - Mark array_index_mask_nospec() __always_inline since GCC may emit an out-of-line call instead of the inline data dependency sequence the mitigation relies on - Clear r12 on kernel entry to prevent potential speculative use of user value in system_call, ext/io/mcck interrupt handlers * tag 's390-7.0-6' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/entry: Scrub r12 register on kernel entry s390/syscalls: Add spectre boundary for syscall dispatch table s390/barrier: Make array_index_mask_nospec() __always_inline
2026-03-28tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.0Ahmed S. Darwish
Update kcpuid's CSV to version 3.0, as generated by x86-cpuid-db. Summary of the v2.5 changes: - Reduce the verbosity of leaf and bitfields descriptions, as formerly requested by Boris. - Leaf 0x8000000a: Add Page Modification Logging (PML) bit. Summary of the v3.0 changes: - Leaf 0x23: Introduce subleaf 2, Auto Counter Reload (ACR) - Leaf 0x23: Introduce subleaf 4/5, PEBS capabilities and counters - Leaf 0x1c: Return LBR depth as a bitmask instead of individual bits - Leaf 0x0a: Use more descriptive PMU bitfield names - Leaf 0x0a: Add various missing PMU events - Leaf 0x06: Add missing IA32_HWP_CTL flag - Leaf 0x0f: Add missing non-CPU (IO) Intel RDT bits Thanks to Dave Hansen for reporting multiple missing bits. Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v2.5/CHANGELOG.rst Link: https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v3.0/CHANGELOG.rst
2026-03-28Merge tag 'renesas-pinctrl-for-v7.1-tag1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel pinctrl: renesas: Updates for v7.1 - Add pin configuration support for RZ/T2H and RZ/N2H, - Fix save/restore of registers for ports with variable pincfg per pin on RZ/G3E, RZ/V2H(P), RZ/V2N, and RZ/Five, - Drop a superfluous blank line. Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-03-28tracing: Remove tracing_alloc_snapshot() when snapshot isn't definedSteven Rostedt
The function tracing_alloc_snapshot() is only used between trace.c and trace_snapshot.c. When snapshot isn't configured, it's not used at all. The stub function was defined as a global with no users and no prototype causing build issues. Remove the function when snapshot isn't configured as nothing is calling it. Also remove the EXPORT_SYMBOL_GPL() that was associated with it as it's not used outside of the tracing subsystem which also includes any modules. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://patch.msgid.link/20260328101946.2c4ef4a5@robin Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/acb-IuZ4vDkwwQLW@sirena.co.uk/ Fixes: bade44fe546212 (tracing: Move snapshot code out of trace.c and into trace_snapshot.c) Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-28ALSA: hda: Add missing SET_GPI_* and SET_GPO_* verb definitionsTakashi Iwai
We've added the definitions of the missing GPI and GPO verbs for reading in the previous commit, but the counter-part for setting values is missing. Add the definitions of missing verbs for comprehensiveness. Link: https://patch.msgid.link/20260328134319.207482-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-28gpu: nova-core: firmware: gsp: use dma::Coherent for level0 tableAlexandre Courbot
Replace the nova-core local `DmaObject` with a `CoherentBox` that can fulfill the same role. Since `CoherentBox` is more flexible than `DmaObject`, we can use the native `u64` type for page table entries instead of messing with bytes. The `dma` module becomes unused with that change, so remove it as well. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-7-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: gsp: use dma::Coherent for signaturesAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-6-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: fb: use dma::CoherentHandleAlexandre Courbot
Replace the nova-core local `DmaObject` with a `CoherentHandle` that can fulfill the same role. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-5-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: falcon: use dma::CoherentAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-4-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: fwsec: use dma::CoherentAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-3-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28gpu: nova-core: firmware: riscv: use dma::CoherentAlexandre Courbot
Replace the nova-core local `DmaObject` with a `Coherent` that can fulfill the same role. Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-2-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28rust: dma: add from-slice constructors for Coherent and CoherentBoxAlexandre Courbot
A very common pattern is to create a block of coherent memory with the content of an already-existing slice of bytes (e.g. a loaded firmware blob). `CoherentBox` makes this easier, but still implies a potentially panicking operation with `copy_from_slice` that requires a `PANIC` comment. Add `from_slice_with_attrs` and `from_slice` methods to both `Coherent` and `CoherentBox` to turn this into a trivial one-step operation. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260327-b4-nova-dma-removal-v2-1-616e1d0b5cb3@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28ALSA: hda/proc: show GPI and GPO state in codec proc outputCássio Gabriel
print_gpio() prints the GPIO capability header and the bidirectional GPIO state, but it never reports the separate GPI and GPO pins even though AC_PAR_GPIO_CAP exposes their counts. The HD-audio specification defines dedicated GPI and GPO verbs alongside the GPIO ones, so codecs with input-only or output-only general-purpose pins currently lose that state from /proc/asound/card*/codec#* altogether. Add the missing read verb definitions and extend print_gpio() to dump the GPI and GPO pins, too, while leaving the existing IO[] output unchanged. Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260328-hda-proc-gpi-gpo-v1-1-fabb36564bee@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-28posix-timers: Fix stale function name in commentZhan Xusheng
The comment in exit_itimers() still refers to itimer_delete(), which was replaced by posix_timer_delete(). Update the comment accordingly. Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260326142210.98632-1-zhanxusheng@xiaomi.com
2026-03-28irqchip/renesas-rzg2l: Replace raw_spin_{lock,unlock} with guard() in ↵Biju Das
rzg2l_irq_set_type() Simplify the locking logic in rzg2l_irq_set_type() by using guard(), eliminating the need for an explicit unlock call. [ tglx: Remove the pointless cleanup.h include. The spinlock guards come from spinlock.h ] Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260328103324.134131-3-biju.das.jz@bp.renesas.com
2026-03-28rust: dma: add CoherentHandle for DMA allocations without kernel mappingDanilo Krummrich
Add CoherentHandle, an opaque DMA allocation type for buffers that are only ever accessed by hardware. Unlike Coherent<T>, it does not provide CPU access to the allocated memory. CoherentHandle implicitly sets DMA_ATTR_NO_KERNEL_MAPPING and stores the value returned by dma_alloc_attrs() as an opaque handle (NonNull<c_void>) rather than a typed pointer, since with this flag the C API returns an opaque cookie (e.g. struct page *), not a CPU pointer to the allocated memory. Only the DMA bus address is exposed to drivers; the opaque handle is used solely to free the allocation on drop. This commit is for reference only; there is currently no in-tree user. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260321172749.592387-2-dakr@kernel.org [acourbot: fix conflict in dma.rs.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28ALSA: usb-audio: Add quirks for Arturia AF16RigPhil Willoughby
The AF16Rig supports 34 channels at 44.1k/48k, 18 channels at 88.2k/96k and 10 channels at 176.4k/192k. This quirks is necessary because the automatic probing process we would otherwise use fails. The root cause of that is that the AF16Rig clock is not readable (its descriptor says that it is but the reads fail). Except as described below, the values in the audio format quirks were copied from the USB descriptors of the device. The rate information is from the datasheet of the device. The clock is the internal clock of the AF16Rig. Tested-By: Phil Willoughby <willerz@gmail.com> I have tested all the configurations enabled by this patch. Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Signed-off-by: Phil Willoughby <willerz@gmail.com> Link: https://patch.msgid.link/20260328112426.14816-1-willerz@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-28ALSA: asihpi: detect truncated control namesPengpeng Hou
asihpi_ctl_init() builds mixer control names in the fixed 44-byte hpi_ctl->name buffer with sprintf(). This is not only a defensive cleanup. The current in-tree name tables and format strings can already exceed 44 bytes. For example, "Bitstream 0 Internal 0 Monitor Playback Volume" is 46 characters before the trailing NUL, so the current sprintf() call writes past the end of hpi_ctl->name. The generated control name is used as the ALSA control element key, so blindly truncating it is not sufficient. Switch the formatting to snprintf() and emit an error if truncation happens, showing the truncated name while still keeping the write bounded to hpi_ctl->name. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260328102808.33969-1-pengpeng@iscas.ac.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-03-28rust: dma: remove DMA_ATTR_NO_KERNEL_MAPPING from public attrsDanilo Krummrich
When DMA_ATTR_NO_KERNEL_MAPPING is passed to dma_alloc_attrs(), the returned CPU address is not a pointer to the allocated memory but an opaque handle (e.g. struct page *). Coherent<T> (or CoherentAllocation<T> respectively) stores this value as NonNull<T> and exposes methods that dereference it and even modify its contents. Remove the flag from the public attrs module such that drivers cannot pass it to Coherent<T> (or CoherentAllocation<T> respectively) in the first place. Instead DMA_ATTR_NO_KERNEL_MAPPING can be supported with an additional opaque type (e.g. CoherentHandle) which does not provide access to the allocated memory. Cc: stable@vger.kernel.org Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Signed-off-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260321172749.592387-1-dakr@kernel.org Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-28futex: Clear stale exiting pointer in futex_lock_pi() retry pathDavidlohr Bueso
Fuzzying/stressing futexes triggered: WARNING: kernel/futex/core.c:825 at wait_for_owner_exiting+0x7a/0x80, CPU#11: futex_lock_pi_s/524 When futex_lock_pi_atomic() sees the owner is exiting, it returns -EBUSY and stores a refcounted task pointer in 'exiting'. After wait_for_owner_exiting() consumes that reference, the local pointer is never reset to nil. Upon a retry, if futex_lock_pi_atomic() returns a different error, the bogus pointer is passed to wait_for_owner_exiting(). CPU0 CPU1 CPU2 futex_lock_pi(uaddr) // acquires the PI futex exit() futex_cleanup_begin() futex_state = EXITING; futex_lock_pi(uaddr) futex_lock_pi_atomic() attach_to_pi_owner() // observes EXITING *exiting = owner; // takes ref return -EBUSY wait_for_owner_exiting(-EBUSY, owner) put_task_struct(); // drops ref // exiting still points to owner goto retry; futex_lock_pi_atomic() lock_pi_update_atomic() cmpxchg(uaddr) *uaddr ^= WAITERS // whatever // value changed return -EAGAIN; wait_for_owner_exiting(-EAGAIN, exiting) // stale WARN_ON_ONCE(exiting) Fix this by resetting upon retry, essentially aligning it with requeue_pi. Fixes: 3ef240eaff36 ("futex: Prevent exit livelock") Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260326001759.4129680-1-dave@stgolabs.net
2026-03-28tracing: Drain deferred trigger frees if kthread creation failsWesley Atwell
Boot-time trigger registration can fail before the trigger-data cleanup kthread exists. Deferring those frees until late init is fine, but the post-boot fallback must still drain the deferred list if kthread creation never succeeds. Otherwise, boot-deferred nodes can accumulate on trigger_data_free_list, later frees fall back to synchronously freeing only the current object, and the older queued entries are leaked forever. To trigger this, add the following to the kernel command line: trace_event=sched_switch trace_trigger=sched_switch.traceon,sched_switch.traceon The second traceon trigger will fail and be freed. This triggers a NULL pointer dereference and crashes the kernel. Keep the deferred boot-time behavior, but when kthread creation fails, drain the whole queued list synchronously. Do the same in the late-init drain path so queued entries are not stranded there either. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260324221326.1395799-3-atwellwea@gmail.com Fixes: 61d445af0a7c ("tracing: Add bulk garbage collection of freeing event_trigger_data") Signed-off-by: Wesley Atwell <atwellwea@gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-28KVM: arm64: Convert gmem_abort() to struct kvm_s2_fault_descMarc Zyngier
Having fully converted user_mem_abort() to kvm_s2_fault_desc and co, convert gmem_abort() to it as well. The change is obviously much simpler. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Simplify integration of adjust_nested_*_perms()Marc Zyngier
Instead of passing pointers to adjust_nested_*_perms(), allow them to return a new set of permissions. With some careful moving around so that the canonical permissions are computed before the nested ones are applied, we end-up with a bit less code, and something a bit more readable. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Directly expose mapping prot and kill kvm_s2_faultMarc Zyngier
The 'prot' field is the only one left in kvm_s2_fault. Expose it directly to the functions needing it, and get rid of kvm_s2_fault. It has served us well during this refactoring, but it is now no longer needed. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Move device mapping management into kvm_s2_fault_pin_pfn()Marc Zyngier
Attributes computed for devices are computed very late in the fault handling process, meanning they are mutable for that long. Introduce both 'device' and 'map_non_cacheable' attributes to the vma_info structure, allowing that information to be set in stone earlier, in kvm_s2_fault_pin_pfn(). Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Replace force_pte with a max_map_size attributeMarc Zyngier
force_pte is annoyingly limited in what it expresses, and we'd be better off with a more generic primitive. Introduce max_map_size instead, which does the trick and can be moved into the vma_info structure. This firther allows it to reduce the scopes in which it is mutable. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Move kvm_s2_fault.{pfn,page} to kvm_s2_vma_infoMarc Zyngier
Continue restricting the visibility/mutability of some attributes by moving kvm_s2_fault.{pfn,page} to kvm_s2_vma_info. This is a pretty mechanical change. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Restrict the scope of the 'writable' attributeMarc Zyngier
The 'writable' field is ambiguous, and indicates multiple things: - whether the underlying memslot is writable - whether we are resolving the fault with writable attributes Add a new field to kvm_s2_fault_vma_info (map_writable) to indicate the former condition, and have local writable variables to track the latter. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Kill logging_active from kvm_s2_faultMarc Zyngier
There are only two spots where we evaluate whether logging is active. Replace the boolean with calls to the relevant helper. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Move VMA-related information to kvm_s2_fault_vma_infoMarc Zyngier
Mecanically extract a bunch of VMA-related fields from kvm_s2_fault and move them to a new kvm_s2_fault_vma_info structure. This is not much, but it already allows us to define which functions can update this structure, and which ones are pure consumers of the data. Those in the latter camp are updated to take a const pointer to that structure. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Kill topup_memcache from kvm_s2_faultMarc Zyngier
The topup_memcache field can be easily replaced by the equivalent conditions, and the resulting code is not much worse. While at it, split prepare_mmu_memcache() into get/topup helpers, which makes the code more readable. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Kill exec_fault from kvm_s2_faultMarc Zyngier
Similarly to write_fault, exec_fault can be advantageously replaced by the kvm_vcpu_trap_is_exec_fault() predicate where needed. Another one bites the dust... Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Kill write_fault from kvm_s2_faultMarc Zyngier
We already have kvm_is_write_fault() as a predicate indicating a S2 fault on a write, and we're better off just using that instead of duplicating the state. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Constrain fault_granule to kvm_s2_fault_map()Marc Zyngier
The notion of fault_granule is specific to kvm_s2_fault_map(), and is unused anywhere else. Move this variable locally, removing it from kvm_s2_fault. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Replace fault_is_perm with a helperMarc Zyngier
Carrying a boolean to indicate that a given fault is a permission fault is slightly odd, as this is a property of the fault itself, and we'd better avoid duplicating state. For this purpose, introduce a kvm_s2_fault_is_perm() predicate that can take a fault descriptor as a parameter. fault_is_perm is therefore dropped from kvm_s2_fault. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Move fault context to const structureMarc Zyngier
In order to make it clearer what gets updated or not during fault handling, move a set of information that losely represents the fault context. This gets populated early, from handle_mem_abort(), and gets passed along as a const pointer. user_mem_abort()'s signature is majorly improved in doing so, and kvm_s2_fault loses a bunch of fields. gmem_abort() will get a similar treatment down the line. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-03-28KVM: arm64: Make fault_ipa immutableMarc Zyngier
Updating fault_ipa is conceptually annoying, as it changes something that is a property of the fault itself. Stop doing so and instead use fault->gfn as the sole piece of state that can be used to represent the faulting IPA. At the same time, introduce get_canonical_gfn() for the couple of case we're we are concerned with the memslot-related IPA and not the faulting one. Tested-by: Fuad Tabba <tabba@google.com> Reviewed-by: Fuad Tabba <tabba@google.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org>