summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-15loop: use READ_ONCE() to read lo->lo_state without lockingYongpeng Yang
When lo->lo_mutex is not held, direct access may read stale data. This patch uses READ_ONCE() to read lo->lo_state and data_race() to silence code checkers, and changes all assignments to use WRITE_ONCE(). Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-12-15kunit: make FAULT_TEST default to n when PANIC_ON_OOPSBrendan Jackman
As describe in the help string, the user might want to disable these tests if they don't like to see stacktraces/BUG etc in their kernel log. However, if they enable PANIC_ON_OOPS, these tests also crash the machine, which it's safe to assume _almost_ nobody wants. One might argue that _absolutely_ nobody ever wants their kernel to crash so this should just be a hard dependency instead of a default. However, since this is rather special code that's anyway concerned with deliberately doing "bad" things, the normal rules don't seem to apply, hence prefer flexibility and allow users to set up a crashing Kconfig if they so choose. Link: https://lore.kernel.org/r/20251207-kunit-fault-no-panic-v1-1-2ac932f26864@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-12-15kunit: Drop unused parameter from kunit_device_register_internalUwe Kleine-König
The passed driver isn't used, so just drop this parameter. Link: https://lore.kernel.org/r/20251210065839.482608-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-12-15drm/panel: sony-td4353-jdi: Enable prepare_prev_firstMarijn Suijten
The DSI host must be enabled before our prepare function can run, which has to send its init sequence over DSI. Without enabling the host first the panel will not probe. Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20251130-sony-akari-fix-panel-v1-1-1d27c60a55f5@somainline.org
2025-12-15Revert "arm64: zynqmp: Add an OP-TEE node to the device tree"Tomas Melin
This reverts commit 06d22ed6b6635b17551f386b50bb5aaff9b75fbe. OP-TEE logic in U-Boot automatically injects a reserved-memory node along with optee firmware node to kernel device tree. The injection logic is dependent on that there is no manually defined optee node. Having the node in zynqmp.dtsi effectively breaks OP-TEE's insertion of the reserved-memory node, causing memory access violations during runtime. Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20251125-revert-zynqmp-optee-v1-1-d2ce4c0fcaf6@vaisala.com
2025-12-15dt-bindings: samsung: exynos-pmu: Add compatible for ARTPEC-9 SoCSungMin Park
Add Axis ARTPEC-9 pmu compatible to the bindings documentation. It reuses the older samsung,exynos7-pmu design. Signed-off-by: SungMin Park <smn1196@coasia.com> Signed-off-by: Ravi Patel <ravi.patel@samsung.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251029130731.51305-5-ravi.patel@samsung.com Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2025-12-15sched_ext: Remove unused code in the do_pick_task_scx()Zqiang
The kick_idle variable is no longer used, this commit therefore remove it and also remove associated code in the do_pick_task_scx(). Signed-off-by: Zqiang <qiang.zhang@linux.dev> Reviewed-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-12-15dt-bindings: crypto: Document aspeed,ahbc property for Aspeed ACRYAndrew Jeffery
The g6 DTSI already provides the property and the driver errors out if the AHB controller's syscon can't be located, so define the property and mark it as required. Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://patch.msgid.link/20251211-dev-dt-warnings-all-v1-10-21b18b9ada77@codeconstruct.com.au Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-15dt-bindings: bus: aspeed: Require syscon for AST2600 AHB controllerAndrew Jeffery
The AST2600's ACRY (eliptic curve and RSA crypto engine) requires access to configuration exposed by the AHB controller. The devicetree already describes the AHB controller node as a syscon, so require this in the binding to satisfy the ACRY relationship. Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au> Link: https://patch.msgid.link/20251211-dev-dt-warnings-all-v1-9-21b18b9ada77@codeconstruct.com.au Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-12-15printk/nbcon: Restore IRQ in atomic flush after each emitted recordPetr Mladek
The commit d5d399efff6577 ("printk/nbcon: Release nbcon consoles ownership in atomic flush after each emitted record") prevented stall of a CPU which lost nbcon console ownership because another CPU entered an emergency flush. But there is still the problem that the CPU doing the emergency flush might cause a stall on its own. Let's go even further and restore IRQ in the atomic flush after each emitted record. It is not a complete solution. The interrupts and/or scheduling might still be blocked when the emergency atomic flush was called with IRQs and/or scheduling disabled. But it should remove the following lockup: mlx5_core 0000:03:00.0: Shutdown was called kvm: exiting hardware virtualization arm-smmu-v3 arm-smmu-v3.10.auto: CMD_SYNC timeout at 0x00000103 [hwprod 0x00000104, hwcons 0x00000102] smp: csd: Detected non-responsive CSD lock (#1) on CPU#4, waiting 5000000032 ns for CPU#00 do_nothing (kernel/smp.c:1057) smp: csd: CSD lock (#1) unresponsive. [...] Call trace: pl011_console_write_atomic (./arch/arm64/include/asm/vdso/processor.h:12 drivers/tty/serial/amba-pl011.c:2540) (P) nbcon_emit_next_record (kernel/printk/nbcon.c:1049) __nbcon_atomic_flush_pending_con (kernel/printk/nbcon.c:1517) __nbcon_atomic_flush_pending.llvm.15488114865160659019 (./arch/arm64/include/asm/alternative-macros.h:254 ./arch/arm64/include/asm/cpufeature.h:808 ./arch/arm64/include/asm/irqflags.h:192 kernel/printk/nbcon.c:1562 kernel/printk/nbcon.c:1612) nbcon_atomic_flush_pending (kernel/printk/nbcon.c:1629) printk_kthreads_shutdown (kernel/printk/printk.c:?) syscore_shutdown (drivers/base/syscore.c:120) kernel_kexec (kernel/kexec_core.c:1045) __arm64_sys_reboot (kernel/reboot.c:794 kernel/reboot.c:722 kernel/reboot.c:722) invoke_syscall (arch/arm64/kernel/syscall.c:50) el0_svc_common.llvm.14158405452757855239 (arch/arm64/kernel/syscall.c:?) do_el0_svc (arch/arm64/kernel/syscall.c:152) el0_svc (./arch/arm64/include/asm/alternative-macros.h:254 ./arch/arm64/include/asm/cpufeature.h:808 ./arch/arm64/include/asm/irqflags.h:73 arch/arm64/kernel/entry-common.c:169 arch/arm64/kernel/entry-common.c:182 arch/arm64/kernel/entry-common.c:749) el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:820) el0t_64_sync (arch/arm64/kernel/entry.S:600) In this case, nbcon_atomic_flush_pending() is called from printk_kthreads_shutdown() with IRQs and scheduling enabled. Note that __nbcon_atomic_flush_pending_con() is directly called also from nbcon_device_release() where the disabled IRQs might break PREEMPT_RT guarantees. But the atomic flush is called only in emergency or panic situations where the latencies are irrelevant anyway. An ultimate solution would be a touching of watchdogs. But it would hide all problems. Let's do it later when anyone reports a stall which does not have a better solution. Closes: https://lore.kernel.org/r/sqwajvt7utnt463tzxgwu2yctyn5m6bjwrslsnupfexeml6hkd@v6sqmpbu3vvu Tested-by: Breno Leitao <leitao@debian.org> Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20251212124520.244483-1-pmladek@suse.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-12-15nvme-pci: disable secondary temp for Wodposit WPBSNM8Ilikara Zheng
Secondary temperature thresholds (temp2_{min,max}) were not reported properly on this NVMe SSD. This resulted in an error while attempting to read these values with sensors(1): ERROR: Can't get value of subfeature temp2_min: I/O error ERROR: Can't get value of subfeature temp2_max: I/O error Add the device to the nvme_id_table with the NVME_QUIRK_NO_SECONDARY_TEMP_THRESH flag to suppress access to all non- composite temperature thresholds. Cc: stable@vger.kernel.org Tested-by: Wu Haotian <rigoligo03@gmail.com> Signed-off-by: Ilikara Zheng <ilikara@aosc.io> Signed-off-by: Keith Busch <kbusch@kernel.org>
2025-12-15MIPS: Fix a reference leak bug in ip22_check_gio()Haoxiang Li
If gio_device_register fails, gio_dev_put() is required to drop the gio_dev device reference. Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28") Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-12-15MIPS: Alchemy: Remove bogus static/inline specifiersThierry Reding
The recent io_remap_pfn_range() rework applied the static and inline specifiers to the implementation of io_remap_pfn_range_pfn() on MIPS Alchemy, mirroring the same change on other platforms. However, this function is defined in a source file and that definition causes a conflict with its declaration. Fix this by dropping the specifiers. Fixes: c707a68f9468 ("mm: abstract io_remap_pfn_range() based on PFN") Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-12-15xtensa: align: validate access in fast_load_storeRicky Ringler
access_ok() is used only in user mode and branches to .Linvalid_instruction on fault. Kernel mode skips access_ok(). Tested-by: Ricky Ringler <richard.rringler@gmail.com> Signed-off-by: Ricky Ringler <richard.rringler@gmail.com> Message-ID: <20251215143323.2771889-1-richard.rringler@gmail.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2025-12-15Merge patch series "filelock: fix conflict detection with userland file ↵Christian Brauner
delegations" Jeff Layton <jlayton@kernel.org> says: This patchset fixes the way that conflicts are detected when userland requests file delegations. The problem is due to a hack that was added long ago which worked up until userland could request a file delegation. This fixes the bug and makes things a bit less hacky. Please consider for v6.19. * patches from https://patch.msgid.link/20251204-dir-deleg-ro-v2-0-22d37f92ce2c@kernel.org: filelock: allow lease_managers to dictate what qualifies as a conflict filelock: add lease_dispose_list() helper Link: https://patch.msgid.link/20251204-dir-deleg-ro-v2-0-22d37f92ce2c@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15filelock: allow lease_managers to dictate what qualifies as a conflictJeff Layton
Requesting a delegation on a file from the userland fcntl() interface currently succeeds when there are conflicting opens present. This is because the lease handling code ignores conflicting opens for FL_LAYOUT and FL_DELEG leases. This was a hack put in place long ago, because nfsd already checks for conflicts in its own way. The kernel needs to perform this check for userland delegations the same way it is done for leases, however. Make this dependent on the lease_manager by adding a new ->lm_open_conflict() lease_manager operation and have generic_add_lease() call that instead of check_conflicting_open(). Morph check_conflicting_open() into a ->lm_open_conflict() op that is only called for userland leases/delegations. Set the ->lm_open_conflict() operations for nfsd to trivial functions that always return 0. Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20251204-dir-deleg-ro-v2-2-22d37f92ce2c@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15filelock: add lease_dispose_list() helperJeff Layton
The lease-handling code paths always know they're disposing of leases, yet locks_dispose_list() checks flags at runtime to determine whether to call locks_free_lease() or locks_free_lock(). Split out a dedicated lease_dispose_list() helper for lease code paths. This makes the type handling explicit and prepares for the upcoming lease_manager enhancements where lease-specific operations are being consolidated. Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Link: https://patch.msgid.link/20251204-dir-deleg-ro-v2-1-22d37f92ce2c@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15iomap: replace folio_batch allocation with stack allocationBrian Foster
Zhang Yi points out that the dynamic folio_batch allocation in iomap_fill_dirty_folios() is problematic for the ext4 on iomap work that is under development because it doesn't sufficiently handle the allocation failure case (by allowing a retry, for example). We've also seen lockdep (via syzbot) complain recently about the scope of the allocation. The dynamic allocation was initially added for simplicity and to help indicate whether the batch was used or not by the calling fs. To address these issues, put the batch on the stack of iomap_zero_range() and use a flag to control whether the batch should be used in the iomap folio lookup path. This keeps things simple and eliminates allocation issues with lockdep and for ext4 on iomap. While here, also clean up the fill helper signature to be more consistent with the underlying filemap helper. Pass through the return value of the filemap helper (folio count) and update the lookup offset via an out param. Fixes: 395ed1ef0012 ("iomap: optional zero range dirty folio processing") Signed-off-by: Brian Foster <bfoster@redhat.com> Link: https://patch.msgid.link/20251208140548.373411-1-bfoster@redhat.com Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15media: mc: fix potential use-after-free in media_request_alloc()Mathias Krause
Commit 6f504cbf108a ("media: convert media_request_alloc() to FD_PREPARE()") moved the call to fd_install() (now hidden in fd_publish()) before the snprintf(), making the later write to potentially already freed memory, as userland is free to call close() concurrently right after the call to fd_install() which may end up in the request_fops.release() handler freeing 'req'. Fixes: 6f504cbf108a ("media: convert media_request_alloc() to FD_PREPARE()") Signed-off-by: Mathias Krause <minipli@grsecurity.net> Link: https://patch.msgid.link/20251209210903.603958-1-minipli@grsecurity.net Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15printk: nbcon: Check for device_{lock,unlock} callbacksMarcos Paulo de Souza
These callbacks are necessary to synchronize ->write_thread callback against other operations using the same device. Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com> Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20251208-nbcon-device-cb-fix-v2-1-36be8d195123@suse.com Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-12-15spi: dt-bindings: st,stm32-spi: add 'power-domains' propertyAlain Volmat
STM32 SPI may be in a power domain which is the case for the STM32MP2x based boards. Allow a single 'power-domains' entry for STM32 SPI. Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20251215-stm32-spi-mp2x-dt-updates-v1-1-464a5fd20f13@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: hda: Only check SSP MCLK mask in case of IPC3Peter Ujfalusi
IPC4 is using the NHLT blob itself and sends the SSP blob from it directly to the firmware, there is no need for the MCLK quirk based on the SSP blob since the SSP blob is in use. At the same time reword the error, info and debug messages for clarity. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Balamurugan C <balamurugan.c@intel.com> Link: https://patch.msgid.link/20251215130819.31218-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: Fix acronym for Intel Gemini LakeAndy Shevchenko
While the used GML is consistent with the pattern for other Intel * Lake SoCs, the de facto use is GLK. Update the acronym and users accordingly. Note, a handful of the drivers for Gemini Lake in the Linux kernel use GLK already (LPC, MEI, pin control, SDHCI, ...) and even some in ASoC. The only ones in this patch used the inconsistent one. Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Link: https://patch.msgid.link/20251212181742.3944789-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: Intel: soc-acpi-intel-nvl-match: Drop rt722 l3 from the match tablePeter Ujfalusi
Revert "ASoC: Intel: soc-acpi-intel-nvl-match: add rt722 l3 support" NVL should be only using functional topologies for products, no monolithic topologies are planned to be released. In parallel a feature has been landed [1] which allows to remove the entries from the match table for sdca codecs to rely solely on function fragments. This reverts commit 41566e3de40616375e8dfe5455344558b79f9354. Link: https://lore.kernel.org/linux-sound/20251014071335.3844631-1-yung-chuan.liao@linux.intel.com/ Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20251215101036.9370-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: soc-acpi / SOF: Add best_effort flag to get_function_tplg_files opPeter Ujfalusi
When there is no fallback possibility available for the function topology use it is better to try to create a profile for the card in best effort manner, leaving out non supported links for example. As an example: some laptops present SSPx-BT link but we don't have fragment yet to support this. If we only have support for functional topology without monolithic fallback then we would fail the card creation. The reason why the monolithic topology works on the same device is that it does not have the SSPx-BT link handled, it is ignored. In case when there is no fallback possibility we should try to create the card with links that we support as best effort instead of failing and leaving the user without a card. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20251215101036.9370-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-nvl: Set on_demand_dsp_boot for NVL-SPeter Ujfalusi
NVL-S can be used with on-demand DSP booting, set the flag to enable it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20251215132946.2155-9-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-ptl: Set on_demand_dsp_boot for PTL and WCLPeter Ujfalusi
PTL and WCL can be used with on-demand DSP booting, set the flag to enable it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-8-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-lnl: Set on_demand_dsp_boot for LNLPeter Ujfalusi
LNL can be used with on-demand DSP booting, set the flag to enable it. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-7-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: hda-sdw-bpt: Add support for on-demand DSP bootPeter Ujfalusi
If on-demand DSP boot is used we need to make sure that the DSP is booted up - which might not be the case - since we need ChainDMA in normal, non DSPless mode for the BRA to work. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-6-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: sof-client: Add support for on-demand DSP bootPeter Ujfalusi
With the introduction of on-demand DSP boot the rpm status not necessary tells that the DSP firmware is booted up. Introduce the sof_client_boot_dsp() which can be used to make sure that the DSP is booted and it can handle IPCs. Update the client drivers to use the new function where it is expected that the DSP is booted up. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-5-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Add support for on-demand DSP bootPeter Ujfalusi
On system suspend / resume we always power up the DSP and boot the firmware, which is not strictly needed as right after the firmware booted up we power the DSP down again on suspend and we also power it down after resume after some inactivity. Out of caution, add a new platform descriptor flag to enable on-demand DSP boot since this might not work without changes to platform code on certain platforms. With the on-demand dsp boot enabled we will not boot the DSP and firmware up on system or rpm resume, just enable audio subsystem since audio IPs, like HDA and SoundWire might be needed (codecs suspend/resume operation). Only boot up the DSP during the first hw_params() call when the DSP is really going to be needed. In this way we can handle the audio related use cases: normal audio use (rpm suspend/resume) system suspend/resume without active audio system suspend/resume with active audio system suspend/resume without active audio, and audio start before the rpm suspend timeout Add module option to force the on-demand DSP boot to allow it to be disabled or enabled without kernel change for testing. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-4-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: control: skip rpm calls in ext_volatile_get if not implementedPeter Ujfalusi
Test earlier for the existence of ext_volatile_get callback and if it is missing, skip the rpm calls to avoid needles DSP power on. No change in functionality, we just skip the DSP power on in the unlikely case when the ext_volatile _get is not supported and yet the topology adds such control. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: ipc4-loader: Remove redundant rpm resume_and_get from load_libraryPeter Ujfalusi
The initial library loading is happening during topology loading, which is already protected with pm_runtime_resume_and_get() via pcm.c The redundant rpm code can be dropped from sof_ipc4_load_library() Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Link: https://patch.msgid.link/20251215132946.2155-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: Intel: pci-mtl: Change the topology path to intel/sof-ipc4-tplgPeter Ujfalusi
The default topology path for IPC4 is intel/sof-ipc4-tplg with a symlink to it as intel/sof-ace-tplg to support old kernels. sof-bin has been released in this manner for almost two years now, it is time to change the default path for MTL family. Link: https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html#topology-file Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://patch.msgid.link/20251215130805.31146-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: ipc4-topology: set playback channel maskBard Liao
Currently, we send all channels to all amps and copy the channel_mask to all ALH DMAs in playback. However, the amp may not have the capability to run any process and SOF may need to split the channels and send specific data channel to each amp. In that case, we need to split the channel_mask in ALH DMA. Copy the channel mask only if the widget channel count is the same the FE channels for playback, otherwise, split the channels among the aggregated DAIs. Like what we did in capture. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/20251215130723.31081-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: topology: Add context when sink or source widget is missingPeter Ujfalusi
Add some context to the error prints when sink or source widget is not found by printing the name of the other side of the connection. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://patch.msgid.link/20251215130741.31106-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15fs/buffer: add alert in try_to_free_buffers() for folios without buffersDeepakkumar Karn
try_to_free_buffers() can be called on folios with no buffers attached when filemap_release_folio() is invoked on a folio belonging to a mapping with AS_RELEASE_ALWAYS set but no release_folio operation defined. In such cases, folio_needs_release() returns true because of the AS_RELEASE_ALWAYS flag, but the folio has no private buffer data. This causes try_to_free_buffers() to call drop_buffers() on a folio with no buffers, leading to a null pointer dereference. Adding a check in try_to_free_buffers() to return early if the folio has no buffers attached, with WARN_ON_ONCE() to alert about the misconfiguration. This provides defensive hardening. Signed-off-by: Deepakkumar Karn <dkarn@redhat.com> Link: https://patch.msgid.link/20251211131211.308021-1-dkarn@redhat.com Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15ASoC: SOF: ipc4-topology: Convert FLOAT to S32 during blob selectionPeter Ujfalusi
SSP/DMIC blobs have no support for FLOAT type, they are using S32 on data bus. Convert the format from FLOAT_LE to S32_LE to make sure that the correct format is used within the path. FLOAT conversion will be done on the host side (or within the path). Fixes: f7c41911ad74 ("ASoC: SOF: ipc4-topology: Add support for float sample type") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20251215120648.4827-3-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15ASoC: SOF: ipc4-topology: Prefer 32-bit DMIC blobs for 8-bit formats as wellPeter Ujfalusi
With the introduction of 8-bit formats the DMIC blob lookup also needs to be modified to prefer the 32-bit blob when 8-bit format is used on FE. At the same time we also need to make sure that in case 8-bit format is used, but only 16-bit blob is available for DMIC then we will not try to look for 8-bit blob (which is invalid) as fallback, but for a 16-bit one. Fixes: c04c2e829649 ("ASoC: SOF: ipc4-topology: Add support for 8-bit formats") Cc: stable@vger.kernel.org Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Seppo Ingalsuo <seppo.ingalsuo@linux.intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20251215120648.4827-2-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-15platform/x86/uniwill: Add TUXEDO Book BA15 Gen10Werner Sembach
Add TUXEDO Book BA15 Gen10 to the list of supported devices of the Uniwill driver. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20251212180319.712913-1-wse@tuxedocomputers.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15platform/x86: alienware-wmi-wmax: Add support for Alienware 16X AuroraKurt Borja
Add AWCC support for Alienware 16X Aurora laptops. Cc: stable@vger.kernel.org Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251205-area-51-v1-3-d2cb13530851@gmail.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15platform/x86: alienware-wmi-wmax: Add AWCC support for Alienware x16Kurt Borja
Add AWCC support for Alienware x16 laptops. Cc: stable@vger.kernel.org Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251205-area-51-v1-2-d2cb13530851@gmail.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15platform/x86: alienware-wmi-wmax: Add support for new Area-51 laptopsKurt Borja
Add AWCC support for new Alienware Area-51 laptops. Cc: stable@vger.kernel.org Signed-off-by: Kurt Borja <kuurtb@gmail.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20251205-area-51-v1-1-d2cb13530851@gmail.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-15selftests: netfilter: packetdrill: avoid failure on HZ=100 kernelFlorian Westphal
packetdrill --ip_version=ipv4 --mtu=1500 --tolerance_usecs=1000000 --non_fatal packet conntrack_syn_challenge_ack.pkt conntrack v1.4.8 (conntrack-tools): 1 flow entries have been shown. conntrack_syn_challenge_ack.pkt:32: error executing `conntrack -f $NFCT_IP_VERSION \ -L -p tcp --dport 8080 | grep UNREPLIED | grep -q SYN_SENT` command: non-zero status 1 Affected kernel had CONFIG_HZ=100; reset packet was still sitting in backlog. Reported-by: Yi Chen <yiche@redhat.com> Fixes: a8a388c2aae4 ("selftests: netfilter: add packetdrill based conntrack tests") Signed-off-by: Florian Westphal <fw@strlen.de>
2025-12-15netfilter: nf_tables: avoid softlockup warnings in nft_chain_validateFlorian Westphal
This reverts commit 314c82841602 ("netfilter: nf_tables: can't schedule in nft_chain_validate"): Since commit a60a5abe19d6 ("netfilter: nf_tables: allow iter callbacks to sleep") the iterator callback is invoked without rcu read lock held, so this cond_resched() is now valid. Signed-off-by: Florian Westphal <fw@strlen.de>
2025-12-15netfilter: nf_tables: avoid chain re-validation if possibleFlorian Westphal
Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate(): watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..] RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_immediate_validate+0x36/0x50 [nf_tables] nft_chain_validate+0xc9/0x110 [nf_tables] nft_table_validate+0x6b/0xb0 [nf_tables] nf_tables_validate+0x8b/0xa0 [nf_tables] nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..] Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps). But there are cases where we could avoid revalidation. Consider: 1 input -> j2 -> j3 2 input -> j2 -> j3 3 input -> j1 -> j2 -> j3 Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3. This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size. We also need to update all reachable chains with the new largest observed call depth. Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains. For example, the masquerade expression can only be called from NAT postrouting base chains. Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location. Reported-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Closes: https://lore.kernel.org/netfilter-devel/20251118221735.GA5477@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/ Tested-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Signed-off-by: Florian Westphal <fw@strlen.de>
2025-12-15drm/rockchip: hdmi: add RK3368 controller variantHeiko Stuebner
The RK3368 has only one VOP, so there is no source selection happening and the controller uses an internal PHY for the HDMI output. Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Andy Yan <andyshrk@163.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251021074254.87065-3-heiko@sntech.de
2025-12-15dt-bindings: display: rockchip: dw-hdmi: Add compatible for RK3368 HDMIHeiko Stuebner
Define a new compatible for RK3368 HDMI. The RK3368 HDMI also uses a PHY internal to the controller, so works similar to other controllers, with the exception that the RK3368 only has one VOP, so there is no source selection needed. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251021074254.87065-2-heiko@sntech.de
2025-12-15fs: Remove internal old mount API codeEric Sandeen
Now that the last in-tree filesystem has been converted to the new mount API, remove all legacy mount API code designed to handle un-converted filesystems, and remove associated documentation as well. (The code to handle the legacy mount(2) syscall from userspace is still in place, of course.) Tested with an allmodconfig build on x86_64, and a sanity check of an old mount(2) syscall mount. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Link: https://patch.msgid.link/20251212174403.2882183-1-sandeen@redhat.com Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-12-15Merge patch series "further damage-control lack of clone scalability"Christian Brauner
Mateusz Guzik <mjguzik@gmail.com> says: When spawning and killing threads in separate processes in parallel the primary bottleneck on the stock kernel is pidmap_lock, largely because of a back-to-back acquire in the common case. Benchmark code at the end. With this patchset alloc_pid() only takes the lock once and consequently alleviates the problem. While scalability improves, the lock remains the primary bottleneck by a large margin. I believe idr is a poor choice for the task at hand to begin with, but sorting out that out beyond the scope of this patchset. At the same time any replacement would be best evaluated against a state where the above relock problem is fixed. Performance improvement varies between reboots. When benchmarking with 20 processes creating and killing threads in a loop, the unpatched baseline hovers around 465k ops/s, while patched is anything between ~510k ops/s and ~560k depending on false-sharing (which I only minimally sanitized). So this is at least 10% if you are unlucky. bench from will-it-scale: char *testcase_description = "Thread creation and teardown"; static void *worker(void *arg) { return (NULL); } void testcase(unsigned long long *iterations, unsigned long nr) { pthread_t thread[1]; int error; while (1) { for (int i = 0; i < 1; i++) { error = pthread_create(&thread[i], NULL, worker, NULL); assert(error == 0); } for (int i = 0; i < 1; i++) { error = pthread_join(thread[i], NULL); assert(error == 0); } (*iterations)++; } } v2: - cosmetic fixes from Oleg - drop idr_preload_many, relock pidmap + call idr_preload again instead - write a commit message for the alloc pid patch * patches from https://patch.msgid.link/20251203092851.287617-1-mjguzik@gmail.com: pid: only take pidmap_lock once on alloc ns: pad refcount Link: https://patch.msgid.link/20251203092851.287617-1-mjguzik@gmail.com Signed-off-by: Christian Brauner <brauner@kernel.org>