summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-01ALSA: lola: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-41-tiwai@suse.de
2025-09-01ALSA: lola: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-40-tiwai@suse.de
2025-09-01ALSA: korg1212: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-39-tiwai@suse.de
2025-09-01ALSA: korg1212: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-38-tiwai@suse.de
2025-09-01ALSA: intel8x0: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-37-tiwai@suse.de
2025-09-01ALSA: ice1712: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-36-tiwai@suse.de
2025-09-01ALSA: ice1712: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-35-tiwai@suse.de
2025-09-01ALSA: fm801: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-34-tiwai@suse.de
2025-09-01ALSA: es1968: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-33-tiwai@suse.de
2025-09-01ALSA: es1968: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-32-tiwai@suse.de
2025-09-01ALSA: es1938: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-31-tiwai@suse.de
2025-09-01ALSA: emu10k1x: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-30-tiwai@suse.de
2025-09-01ALSA: emu10k1: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-29-tiwai@suse.de
2025-09-01ALSA: emu10k1: Use guard() for emu1010 FPGA lockingTakashi Iwai
The snd_emu1010_fpga_lock() and _unlock() call pairs can be simplified gracefully with the introduction of guard(). Only code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-28-tiwai@suse.de
2025-09-01ALSA: emu10k1: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-27-tiwai@suse.de
2025-09-01ALSA: echoaudio: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-26-tiwai@suse.de
2025-09-01ALSA: echoaudio: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-25-tiwai@suse.de
2025-09-01ALSA: ctxfi: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-24-tiwai@suse.de
2025-09-01ALSA: ctxfi: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-23-tiwai@suse.de
2025-09-01ALSA: cs5535audio: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-22-tiwai@suse.de
2025-09-01ALSA: cs46xx: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-21-tiwai@suse.de
2025-09-01ALSA: cs46xx: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-20-tiwai@suse.de
2025-09-01ALSA: cs4281: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-19-tiwai@suse.de
2025-09-01ALSA: cmipci: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-18-tiwai@suse.de
2025-09-01ALSA: cmipci: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-17-tiwai@suse.de
2025-09-01ALSA: ca0106: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-16-tiwai@suse.de
2025-09-01ALSA: bt87x: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-15-tiwai@suse.de
2025-09-01ALSA: aw2: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-14-tiwai@suse.de
2025-09-01ALSA: aw2: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-13-tiwai@suse.de
2025-09-01ALSA: atiixp: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-12-tiwai@suse.de
2025-09-01ALSA: atiixp: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-11-tiwai@suse.de
2025-09-01ALSA: ad1889: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-10-tiwai@suse.de
2025-09-01ALSA: als4000: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-9-tiwai@suse.de
2025-09-01ALSA: als300: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-8-tiwai@suse.de
2025-09-01ALSA: ens137x: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-7-tiwai@suse.de
2025-09-01ALSA: ens137x: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-6-tiwai@suse.de
2025-09-01ALSA: azt3328: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-5-tiwai@suse.de
2025-09-01ALSA: ali5451: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-4-tiwai@suse.de
2025-09-01ALSA: ac97: Use guard() for spin locksTakashi Iwai
Clean up the code using guard() for spin locks. Merely code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-3-tiwai@suse.de
2025-09-01ALSA: ac97: Use guard() for mutex locksTakashi Iwai
Replace the manual mutex lock/unlock pairs with guard() for code simplification. Only code refactoring, and no behavior change. Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20250829144342.4290-2-tiwai@suse.de
2025-09-01ALSA: hda/hdmi: Add pin fix for another HP EliteDesk 800 G4 modelTakashi Iwai
It was reported that HP EliteDesk 800 G4 DM 65W (SSID 103c:845a) needs the similar quirk for enabling HDMI outputs, too. This patch adds the corresponding quirk entry. Cc: <stable@vger.kernel.org> Link: https://patch.msgid.link/20250901115009.27498-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-09-01dm: fix "writen"->"written"Xichao Zhao
Trivial fix to spelling mistake in comment text. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-09-01dm-pcache: cleanup: fix coding style report by checkpatch.plDongsheng Yang
A patch from a few days ago fixed the division issue on 32-bit machines, but it introduced a coding style problem. WARNING: Missing a blank line after declarations + u32 rem; + div_u64_rem(off >> PCACHE_CACHE_SUBTREE_SIZE_SHIFT, cache->n_ksets, &rem); total: 0 errors, 1 warnings, 634 lines checked Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-09-01dm-pcache: remove ctrl_lock for pcache_cache_segmentDongsheng Yang
The smatch checker reports a “scheduler in atomic context” problem in the following call chain: miss_read_end_req() -> cache_seg_put() -> cache_seg_invalidate() -> cache_seg_gen_increase() -> mutex_lock(&cache_seg->ctrl_lock); In practice, this `mutex_lock` will not actually schedule, because it is only called when `cache_seg_put()` drops the last reference, which is single-threaded. That is also why the issue never shows up during real testing. However, the code is still buggy. The original purpose of `ctrl_lock` was to prevent read/write conflicts on the cache segment control information. Looking at the current usage, all control information accesses are single-threaded: reads only occur during the init phase, where no conflicts are possible, and writes happen once in the init phase (also single-threaded) and once when `cache_seg_put()` drops the last reference (again single-threaded). Therefore, this patch removes `ctrl_lock` entirely and adds comments in the appropriate places to document this logic. Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-09-01x86/sev: Indicate the SEV-SNP guest supports Secure AVICNeeraj Upadhyay
Now that Secure AVIC support is complete, make it part of to the SNP present features. Co-developed-by: Kishon Vijay Abraham I <kvijayab@amd.com> Signed-off-by: Kishon Vijay Abraham I <kvijayab@amd.com> Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Link: https://lore.kernel.org/20250828113225.209174-1-Neeraj.Upadhyay@amd.com
2025-09-01x86/sev: Prevent SECURE_AVIC_CONTROL MSR interception for Secure AVIC guestsNeeraj Upadhyay
The SECURE_AVIC_CONTROL MSR holds the GPA of the guest APIC backing page and bitfields to control enablement of Secure AVIC and whether the guest allows NMIs to be injected by the hypervisor. This MSR is populated by the guest and can be read by the guest to get the GPA of the APIC backing page. The MSR can only be accessed in Secure AVIC mode. Any attempt to access it when not in Secure AVIC mode results in #GP. So, the hypervisor should not intercept it. A #VC exception will be generated otherwise. If this occurs and Secure AVIC is enabled, terminate the guest execution. Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Link: https://lore.kernel.org/20250828113119.209135-1-Neeraj.Upadhyay@amd.com
2025-09-01x86/apic: Enable Secure AVIC in the control MSRNeeraj Upadhyay
With all the pieces in place now, enable Secure AVIC in the Secure AVIC Control MSR. Any access to x2APIC MSRs are emulated by the hypervisor before Secure AVIC is enabled in the control MSR. Post Secure AVIC enablement, all x2APIC MSR accesses (whether accelerated by AVIC hardware or trapped as a #VC exception) operate on the vCPU's APIC backing page. Signed-off-by: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Link: https://lore.kernel.org/20250828112126.209028-1-Neeraj.Upadhyay@amd.com
2025-09-01ALSA: usb-audio: Allow Focusrite devices to use low sampleratesTina Wuest
Commit 05f254a6369ac020fc0382a7cbd3ef64ad997c92 ("ALSA: usb-audio: Improve filtering of sample rates on Focusrite devices") changed the check for max_rate in a way which was overly restrictive, forcing devices to use very high samplerates if they support them, despite support existing for lower rates as well. This maintains the intended outcome (ensuring samplerates selected are supported) while allowing devices with higher maximum samplerates to be opened at all supported samplerates. This patch was tested with a Clarett+ 8Pre USB Fixes: 05f254a6369a ("ALSA: usb-audio: Improve filtering of sample rates on Focusrite devices") Signed-off-by: Tina Wuest <tina@wuest.me> Link: https://patch.msgid.link/20250901092024.140993-1-tina@wuest.me Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-09-01cramfs: Verify inode mode when loading from diskTetsuo Handa
The inode mode loaded from corrupted disk can be invalid. Do like what commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk") does. Reported-by: syzbot <syzbot+895c23f6917da440ed0d@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Link: https://lore.kernel.org/429b3ef1-13de-4310-9a8e-c2dc9a36234a@I-love.SAKURA.ne.jp Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-09-01drm/imagination: Enable PowerVR driver for RISC-VMichal Wilczynski
Several RISC-V boards feature Imagination GPUs that are compatible with the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi 4A board. This commit adjusts the driver's Kconfig dependencies to allow the PowerVR driver to be compiled on the RISC-V architecture. By enabling compilation on RISC-V, we expand support for these GPUs, providing graphics acceleration capabilities and enhancing hardware compatibility on RISC-V platforms. The RISC-V support is restricted to 64-bit systems (RISCV && 64BIT) as the driver currently has an implicit dependency on a 64-bit platform. Add a dependency on MMU to fix a build warning on RISC-V configurations without an MMU. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-4-af656f7cc6c3@samsung.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>