summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-19vfio/nvgrace-gpu: register device memory for poison handlingAnkit Agrawal
The nvgrace-gpu module [1] maps the device memory to the user VA (Qemu) without adding the memory to the kernel. The device memory pages are PFNMAP and not backed by struct page. The module can thus utilize the MM's PFNMAP memory_failure mechanism that handles ECC/poison on regions with no struct pages. The kernel MM code exposes register/unregister APIs allowing modules to register the device memory for memory_failure handling. Make nvgrace-gpu register the GPU memory with the MM on open. The module registers its memory region, the address_space with the kernel MM for ECC handling and implements a callback function to convert the PFN to the file page offset. The callback functions checks if the PFN belongs to the device memory region and is also contained in the VMA range, an error is returned otherwise. Link: https://lore.kernel.org/all/20240220115055.23546-1-ankita@nvidia.com/ [1] Suggested-by: Alex Williamson <alex@shazbot.org> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Reviewed-by: Jiaqi Yan <jiaqiyan@google.com> Link: https://lore.kernel.org/r/20260115202849.2921-3-ankita@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19mm: add stubs for PFNMAP memory failure registration functionsAnkit Agrawal
Add stubs to address CONFIG_MEMORY_FAILURE disabled. Suggested-by: Alex Williamson <alex@shazbot.org> Signed-off-by: Ankit Agrawal <ankita@nvidia.com> Link: https://lore.kernel.org/r/20260115202849.2921-2-ankita@nvidia.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19vfio: selftests: Drop IOMMU mapping size assertions for VFIO_TYPE1_IOMMUDavid Matlack
Drop the assertions about IOMMU mappings sizes for VFIO_TYPE1_IOMMU modes (both the VFIO mode and the iommufd compatibility mode). These assertions fail when CONFIG_IOMMUFD_VFIO_CONTAINER is enabled, since iommufd compatibility mode provides different huge page behavior than VFIO for VFIO_TYPE1_IOMMU. VFIO_TYPE1_IOMMU is an old enough interface that it's not worth changing the behavior of VFIO and iommufd to match nor care about the IOMMU mapping sizes. Cc: Jason Gunthorpe <jgg@ziepe.ca> Link: https://lore.kernel.org/kvm/20260109143830.176dc279@shazbot.org/ Signed-off-by: David Matlack <dmatlack@google.com> Link: https://lore.kernel.org/r/20260114211252.2581145-1-dmatlack@google.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19vfio: selftests: Add vfio_dma_mapping_mmio_testAlex Mastro
Test IOMMU mapping the BAR mmaps created during vfio_pci_device_setup(). All IOMMU modes are tested: vfio_type1 variants are expected to succeed, while non-type1 modes are expected to fail. iommufd compat mode can be updated to expect success once kernel support lands. Native iommufd will not support mapping vaddrs backed by MMIO (it will support dma-buf based MMIO mapping instead). Signed-off-by: Alex Mastro <amastro@fb.com> Reviewed-by: David Matlack <dmatlack@google.com> Tested-by: David Matlack <dmatlack@google.com> Link: https://lore.kernel.org/r/20260114-map-mmio-test-v3-3-44e036d95e64@fb.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19vfio: selftests: Align BAR mmaps for efficient IOMMU mappingAlex Mastro
Update vfio_pci_bar_map() to align BAR mmaps for efficient huge page mappings. The manual mmap alignment can be removed once mmap(!MAP_FIXED) on vfio device fds improves to automatically return well-aligned addresses. Also add MADV_HUGEPAGE, which encourages the kernel to use huge pages (e.g. when /sys/kernel/mm/transparent_hugepage/enabled is set to "madvise"). Drop MAP_FILE from mmap(). It is an ignored compatibility flag. Signed-off-by: Alex Mastro <amastro@fb.com> Reviewed-by: David Matlack <dmatlack@google.com> Tested-by: David Matlack <dmatlack@google.com> Link: https://lore.kernel.org/r/20260114-map-mmio-test-v3-2-44e036d95e64@fb.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19vfio: selftests: Centralize IOMMU mode name definitionsAlex Mastro
Replace scattered string literals with MODE_* macros in iommu.h. This provides a single source of truth for IOMMU mode name strings. Signed-off-by: Alex Mastro <amastro@fb.com> Reviewed-by: David Matlack <dmatlack@google.com> Tested-by: David Matlack <dmatlack@google.com> Link: https://lore.kernel.org/r/20260114-map-mmio-test-v3-1-44e036d95e64@fb.com Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19vfio/mdev: update outdated commentJulia Lawall
The function add_mdev_supported_type() was renamed mdev_type_add() in commit da44c340c4fe ("vfio/mdev: simplify mdev_type handling"). Update the comment accordingly. Note that just as mdev_type_release() now states that its put pairs with the get in mdev_type_add(), mdev_type_add() already stated that its get pairs with the put in mdev_type_release(). Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by: Kirti Wankhede <kwankhede@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20251230164113.102604-1-Julia.Lawall@inria.fr Signed-off-by: Alex Williamson <alex@shazbot.org>
2026-01-19pwm: Ensure ioctl() returns a negative errno on errorUwe Kleine-König
copy_to_user() returns the number of bytes not copied, thus if there is a problem a positive number. However the ioctl callback is supposed to return a negative error code on error. This error is a unfortunate as strictly speaking it became ABI with the introduction of pwm character devices. However I never saw the issue in real life -- I found this by code inspection -- and it only affects an error case where readonly memory is passed to the ioctls or the address mapping changes while the ioctl is active. Also there are already error cases returning negative values, so the calling code must be prepared to see such values already. Fixes: 9c06f26ba5f5 ("pwm: Add support for pwmchip devices for faster and easier userspace access") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20260119151325.571857-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2026-01-19spi: rockchip: Use plain request_irq()Mark Brown
The Rockchip driver has since interrupt support was added used request_threaded_irq() but not actually supplied a threaded handler, handling everything in the primary handler. This is equivalent to just using a plain request_irq(), and since aef30c8d569c (genirq: Warn about using IRQF_ONESHOT without a threaded handler) the current behaviour has triggered a WARN_ON(). Convert to use request_irq(). Reported-by: Aishwarya TCV <Aishwarya.TCV@arm.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260116-spi-rockchip-threaded-irq-v1-1-c45c3a5a38b1@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ALSA: hda/realtek: Fix headset mic for TongFang X6AR55xUTim Guttzeit
Add a PCI quirk to enable microphone detection on the headphone jack of TongFang X6AR55xU devices. Signed-off-by: Tim Guttzeit <t.guttzeit@tuxedocomputers.com> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Link: https://patch.msgid.link/20260119151626.35481-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-19clk: qcom: dispcc-sdm845: Enable parents for pixel clocksPetr Hodina
Add CLK_OPS_PARENT_ENABLE to MDSS pixel clock sources to ensure parent clocks are enabled during clock operations, preventing potential stability issues during display configuration. Fixes: 81351776c9fb ("clk: qcom: Add display clock controller driver for SDM845") Signed-off-by: Petr Hodina <petr.hodina@protonmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: David Heidelberg <david@ixit.cz> Link: https://lore.kernel.org/r/20260107-stability-discussion-v2-1-ef7717b435ff@protonmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-19ARM: dts: qcom: msm8974: Start using rpmpd for power domainsLuca Weiss
Due to historical reasons all msm8974 boards have used the CX power rail as regulator instead of going through the power domain framework. Since rpmpd has gained msm8974 support quite a bit ago, let's start using it and replace all usages of pm8841_s2 (CX), pm8841_s4 (GFX) and for the boards using pma8084 pma8084_s2 (CX), pma8084_s7 (GFX). For reference, downstream is using GFX power rail as parent-supply for mmcc's OXILI_GDSC GDSC which then is used for GPU, but nothing there is modelled upstream. Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250621-msm8974-rpmpd-switch-v1-4-0a2cb303c446@lucaweiss.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-19ARM: dts: qcom: msm8974: Sort header includes alphabeticallyLuca Weiss
Before adding more headers in a random order, let's sort the includes once so that's done. Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250621-msm8974-rpmpd-switch-v1-3-0a2cb303c446@lucaweiss.eu Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-19dt-bindings: display: mediatek: Fix typo 'hardwares' to 'hardware'Nauman Sabir
Fix incorrect plural form of the uncountable noun 'hardware' in the MediaTek DP binding description. Signed-off-by: Nauman Sabir <officialnaumansabir@gmail.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patchwork.kernel.org/project/dri-devel/patch/20260112160759.19027-1-officialnaumansabir@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2026-01-19dm-integrity: fix recalculation in bitmap modeMikulas Patocka
There's a logic quirk in the handling of suspend in the bitmap mode: This is the sequence of calls if we are reloading a dm-integrity table: * dm_integrity_ctr reads a superblock with the flag SB_FLAG_DIRTY_BITMAP set. * dm_integrity_postsuspend initializes a journal and clears the flag SB_FLAG_DIRTY_BITMAP. * dm_integrity_resume sees the superblock with SB_FLAG_DIRTY_BITMAP set - thus it interprets the journal as if it were a bitmap. This quirk causes recalculation problem if the user increases the size of the device in the bitmap mode. Fix this by reading a fresh copy on the superblock in dm_integrity_resume. This commit also fixes another logic quirk - the branch that sets bitmap bits if the device was extended should only be executed if the flag SB_FLAG_DIRTY_BITMAP is set. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Tested-by: Ondrej Kozina <okozina@redhat.com> Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org
2026-01-19KVM: s390: vsie: retry SIE when unable to get vsie_pageEric Farman
SIE may exit because of pending host work, such as handling an interrupt, in which case VSIE rewinds the guest PSW such that it is transparently resumed (see Fixes tag). Unlike those other places that return rc=0, this return leaves the guest PSW in place, requiring the guest to handle a spurious intercept. This showed up when testing heavy I/O workloads, when multiple vcpus attempted to dispatch the same SIE block and incurred failures inserting them into the radix tree. Fixes: 33a729a1770b ("KVM: s390: vsie: retry SIE instruction on host intercepts") Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> [frankja@linux.ibm.com: Replaced commit message as agreed on the list] Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
2026-01-19spi: Drop duplicate device_set_node() callAndy Shevchenko
The SPI core provides the default fwnode for the controller, assigned by device_set_node(). No need to repeat it in the driver. Tested-by: Benoît Monin <benoit.monin@bootlin.com> # dw mobileye Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260112203534.4186261-5-andriy.shevchenko@linux.intel.com Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19spi: Drop duplicate fwnode assignmentAndy Shevchenko
The SPI core provides the default fwnode for the controller, inherited from the actual (parent) device. No need to repeat it in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260112203534.4186261-4-andriy.shevchenko@linux.intel.com Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19spi: Drop duplicate of_node assignmentAndy Shevchenko
The SPI core provides the default of_node for the controller, inherited from the actual (parent) device. No need to repeat it in the driver. Acked-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: William Zhang <william.zhang@broadcom.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> # sun4i, sun6i Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260112203534.4186261-3-andriy.shevchenko@linux.intel.com Tested-by: Prajna Rajendra Kumar <prajna.rajendrakumar@microchip.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19spi: Propagate default fwnode to the SPI controller deviceAndy Shevchenko
Most of the SPI controller drivers share the parent's fwnode by explicit assignment. Propagate the default by SPI core, so they may drop that in the code. Only corner cases may require a special treatment and we simply (re)assign the controller's fwnode explicitly (as it's done right now, no changes required for that). Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260112203534.4186261-2-andriy.shevchenko@linux.intel.com Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19dt-bindings: regulator: mark regulator-suspend-microvolt as deprecatedPeng Fan
The Documentation/devicetree/bindings/regulator/regulator.yaml already states in its description that regulator-suspend-microvolt is deprecated, but the schema did not formally mark it as such. Add the `deprecated: true` annotation to regulator-suspend-microvolt so that this is enforced at the schema level. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://patch.msgid.link/20260119-regulator-binding-v1-1-e55d33b4c3e3@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: realtek: fix misspelling of "minimum" in commentsRunrun Liu
Fix the typo "miniumum" -> "minimum" in comments in rt5659, rt5665, rt5668, and rt5682-i2c codec drivers. This typo is already listed in scripts/spelling.txt by commit 8c3200265787 ("scripts/spelling.txt: add several more common spelling mistakes"). Suggested-by: Cryolitia PukNgae <cryolitia@uniontech.com> Signed-off-by: Runrun Liu <liurunrun@uniontech.com> Link: https://patch.msgid.link/3D20FA99934F2891+20260119025302.1288888-1-liurunrun@uniontech.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: codecs: es8323: Enable proper DAPM widgets for chip powerBinbin Zhou
Remove initialization of the chip power register from the es8323_set_bias_level routine, and add proper DAPM power supply widgets to DAPM, which really should be handled by the DAPM subsystem. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/db47e56e7c72bb900a84a33ee07d4ffcf0a908a3.1768641428.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: codecs: es8323: Enable proper DAPM widgets for capture ADCBinbin Zhou
Add proper DAPM capture ADC widgets to DAPM, which really should be handled by the DAPM subsystem. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/9d93040f4cea77054e669c50325e080dffa7a7f1.1768641428.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: codecs: es8323: remove DAC enablement write from es8323_set_bias_levelBinbin Zhou
Since commit daf855f76a12 ("ASoC: es8323: enable DAPM power widgets for playback DAC"), the DAC is handled by the DAPM subsystem. Remove initialization of the DAC enablement bits from the es8323_set_bias_level routine Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/d2823ad7ae226a83d49bcb860240c0ddc4080f14.1768641428.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: codecs: es8323: Replace magic numbers with defined macrosBinbin Zhou
According to the manual, add more detailed register bitfield definitions to replace the magic numbers in the register settings in es8323 codec. No functional change intended. Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> Link: https://patch.msgid.link/7e8953f2d36a86e9d507d6bb01c72b64846e0829.1768641428.git.zhoubinbin@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: soc-acpi-intel-ptl-match: use aggregated endpoint in ↵Bard Liao
ptl_rt722_l0_rt1320_l23 The rt722 amp and rt1320 amps are aggregated in this case. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20260119091749.1752088-3-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: soc-acpi-intel-arl-match: change rt722 amp endpoint to aggregatedBard Liao
rt722 is aggregated with rt1320 amp in arl_rt722_l0_rt1320_l2 and it is the only audio configuration in the ARL platform. Set .aggregated = 1 to represent the fact and avoid unexpected issue. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://patch.msgid.link/20260119091749.1752088-2-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19regulator: fp9931: Add missing memory allocation checkFelix Gu
Add a check for devm_kzalloc failure in fp9931_probe to prevent a null pointer dereference. Fixes: 12d821bd13d4 ("regulator: Add FP9931/JD9930 driver") Signed-off-by: Felix Gu <gu_0233@qq.com> Link: https://patch.msgid.link/tencent_5FCF2108621C51007E5526A7C60A5CC1F306@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: dt-bindings: fsl,sai: Add support for i.MX952 platformShengjiu Wang
Add a new compatible string 'fsl,imx952-sai' for i.MX952 platform, which is fallback compatible with 'fsl,imx95-sai'. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260115061418.4131432-1-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19ASoC: cs35l45: Corrects ASP_TX5 DAPM widget channelRicardo Rivera-Matos
ASP_TX5 was incorrectly mapped to a channel value of 3 corrects, the channel value of 4. Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com> Link: https://patch.msgid.link/20260115192523.1335742-2-rriveram@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-19dm-bufio: avoid redundant buffer_tree lookupsEric Biggers
dm-bufio's map from block number to buffer is organized as a hash table of red-black trees. It does far more lookups in this hash table than necessary: typically one lookup to lock the tree, one lookup to search the tree, and one lookup to unlock the tree. Only one of those lookups is needed. Optimize it to do only the minimum number of lookups. This improves performance. It also reduces the object code size, considering that the redundant hash table lookups were being inlined. For example, the size of the text section of dm-bufio.o decreases from 15599 to 15070 bytes with gcc 15 and x86_64, or from 20652 to 20244 bytes with clang 21 and arm64. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-19dm-bufio: merge cache_put() into cache_put_and_wake()Eric Biggers
Merge cache_put() into its only caller, cache_put_and_wake(). Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-19x86/sev: Rename sev_es_ghcb_handle_msr() to __vc_handle_msr()Borislav Petkov (AMD)
Forgot to do that during the Secure AVIC review. :-\ No functional changes. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Link: https://patch.msgid.link/20260119141310.29605-1-bp@kernel.org
2026-01-19selftests: add dm-verity keyring selftestsChristian Brauner
Add selftests that verify the keyring behaves correctly. For simplicity this works with dm-verity as a module. Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-19dm-verity: add dm-verity keyringChristian Brauner
Add a dedicated ".dm-verity" keyring for root hash signature verification, similar to the ".fs-verity" keyring used by fs-verity. By default the keyring is unused retaining the exact same old behavior. For systems that provision additional keys only intended for dm-verity images during boot, the dm_verity.keyring_unsealed=1 kernel parameter leaves the keyring open. We want to use this in systemd as a way add keys during boot that are only used for creating dm-verity devices for later mounting and nothing else. The discoverable disk image (DDI) spec at [1] heavily relies on dm-verity and we would like to expand this even more. This will allow us to do that in a fully backward compatible way. Once provisioning is complete, userspace restricts and activates it for dm-verity verification. If userspace fully seals the keyring then it gains the guarantee that no new keys can be added. Link: https://uapi-group.org/specifications/specs/discoverable_partitions_specification [1] Co-developed-by: Aleksa Sarai <cyphar@cyphar.com> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-19rust: debugfs: Use kernel Atomic type in docs exampleFUJITA Tomonori
Switch the read_callback_file() documentation example from core::sync::atomic::AtomicU32 to the kernel's Atomic because Rust native atomics are not allowed to use in kernel. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://patch.msgid.link/20251203000411.30434-1-fujita.tomonori@gmail.com [ Use kernel vertical import style. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-19io_uring/rw: free potentially allocated iovec on cache put failureJens Axboe
If a read/write request goes through io_req_rw_cleanup() and has an allocated iovec attached and fails to put to the rw_cache, then it may end up with an unaccounted iovec pointer. Have io_rw_recycle() return whether it recycled the request or not, and use that to gauge whether to free a potential iovec or not. Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-19dma-buf: Remove DMA-BUF sysfs statsT.J. Mercier
Commit bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") added dmabuf statistics to sysfs in 2021 under CONFIG_DMABUF_SYSFS_STATS. After being used in production, performance problems were discovered leading to its deprecation in 2022 in commit e0a9f1fe206a ("dma-buf: deprecate DMABUF_SYSFS_STATS"). Some of the problems with this interface were discussed in my LPC 2025 talk. [1][2] Android was probably the last user of the interface, which has since been migrated to use the dmabuf BPF iterator [3] to obtain the same information more cheaply. As promised in that series, now that the longterm stable 6.18 kernel has been released let's remove the sysfs dmabuf statistics from the kernel. [1] https://www.youtube.com/watch?v=D83qygudq9c [2] https://lpc.events/event/19/contributions/2118/ [3] https://lore.kernel.org/all/20250522230429.941193-1-tjmercier@google.com/ Signed-off-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260116190517.3268458-1-tjmercier@google.com
2026-01-19dma-buf: system_heap: account for system heap allocation in memcgEric Chanudet
The system dma-buf heap lets userspace allocate buffers from the page allocator. However, these allocations are not accounted for in memcg, allowing processes to escape limits that may be configured. Pass __GFP_ACCOUNT for system heap allocations, based on the dma_heap.mem_accounting parameter, to use memcg and account for them. Signed-off-by: Eric Chanudet <echanude@redhat.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260116-dmabuf-heap-system-memcg-v3-2-ecc6b62cc446@redhat.com
2026-01-19dma-buf: heaps: add parameter to account allocations using cgroupEric Chanudet
Add a parameter to enable dma-buf heaps allocation accounting using cgroup for heaps that implement it. It is disabled by default as doing so incurs caveats based on how memcg currently accounts for shared buffers. Signed-off-by: Eric Chanudet <echanude@redhat.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patch.msgid.link/20260116-dmabuf-heap-system-memcg-v3-1-ecc6b62cc446@redhat.com
2026-01-19MAINTAINERS: Adjust vdso file entry in INTEL SGXLukas Bulwahn
Commit 693c819fedcd ("x86/entry/vdso: Refactor the vdso build") moves the vdso sources into common, vdso32, and vdso64 subdirectories, but misses to adjust the file entry in the INTEL SGX section of the MAINTAINERS file. Adjust the file entry in accordance with the file movement of the commit above. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260119093835.114554-1-lukas.bulwahn@redhat.com
2026-01-19ALSA: ctxfi: Fix potential OOB access in audio mixer handlingTakashi Iwai
In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices. Reported-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Karsten Hohmeier <linux@hohmatik.de> Closes: https://bugs.debian.org/1121535 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/all/aSk8KJI35H7gFru6@eldamar.lan/ Link: https://patch.msgid.link/20260119133212.189129-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-19soc: mediatek: mtk-cmdq: Add mminfra_offset adjustment for DRAM addressesJason-JH Lin
Since GCE has been moved to MMINFRA in MT8196, all transactions from MMINFRA to DRAM will have their addresses adjusted by subtracting a mminfra_offset. Therefore, the CMDQ helper driver needs to get the mminfra_offset value of the SoC from cmdq_mbox_priv of cmdq_pkt and then add it to the DRAM address when generating instructions to ensure GCE accesses the correct DRAM address. CMDQ users can then call CMDQ helper APIs as usual. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-19soc: mediatek: mtk-cmdq: Extend cmdq_pkt_write API for SoCs without subsys IDJason-JH Lin
This patch extends the cmdq_pkt_write API to support SoCs that do not have subsys ID mapping by introducing new register write APIs: - cmdq_pkt_write_pa() and cmdq_pkt_write_subsys() replace cmdq_pkt_write() - cmdq_pkt_write_mask_pa() and cmdq_pkt_write_mask_subsys() replace cmdq_pkt_write_mask() To ensure consistent function pointer interfaces, both cmdq_pkt_write_pa() and cmdq_pkt_write_subsys() provide subsys and pa_base parameters. This unifies how register writes are invoked, regardless of whether subsys ID is supported by the device. All GCEs support writing registers by PA (with mask) without subsys, but this requires extra GCE instructions to convert the PA into a GCE readable format, reducing performance compared to using subsys directly. Therefore, subsys is preferred for register writes when available. API documentation and function pointer declarations in cmdq_client_reg have been updated. The original write APIs will be removed after all CMDQ users transition to the new interfaces. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-19soc: mediatek: mtk-cmdq: Add pa_base parsing for hardware without subsys ID ↵Jason-JH Lin
support When GCE executes instructions, it typically locates the corresponding hardware register using the subsys ID. For hardware that does not support subsys ID, the subsys ID is set to an invalid value, and the physical address must be used to generate GCE instructions. The main advantage of using subsys ID is to reduce the number of instructions. Without subsys ID, an additional `ASSIGN` instruction is needed to assign the high bytes of the physical address, which can impact performance if too many instructions are required. However, if the hardware does not support subsys ID, using the physical address is the only option to achieve the same functionality. This commit adds a pa_base parsing flow to the cmdq_client_reg structure to handle hardware without subsys ID support. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-19soc: mediatek: mtk-cmdq: Add cmdq_get_mbox_priv() in cmdq_pkt_create()Jason-JH Lin
Add cmdq_get_mbox_priv() in cmdq_pkt_create() to ensure getting private data before generating GCE instructions. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-19mailbox: mtk-cmdq: Add driver data to support for MT8196Jason-JH Lin
MT8196 has 2 new hardware configuration compared with the previous SoC, which correspond to the 2 new driver data: 1. mminfra_offset: For GCE data path control Since GCE has been moved into mminfra, GCE needs to append the mminfra offset to the DRAM address when accessing the DRAM. 2. gce_vm: For GCE hardware virtualization control Currently, the first version of the mt8196 mailbox controller only requires setting the VM-related registers to enable the permissions of a host VM. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-19mailbox: mtk-cmdq: Add mminfra_offset configuration for DRAM transactionJason-JH Lin
The GCE in MT8196 is placed in MMINFRA and requires all addresses in GCE instructions for DRAM transactions to be IOVA. Due to MMIO, if the GCE needs to access a hardware register at 0x1000_0000, but the SMMU is also mapping a DRAM block at 0x1000_0000, the MMINFRA will not know whether to write to the hardware register or the DRAM. To solve this, MMINFRA treats addresses greater than 2G as data paths and those less than 2G as config paths because the DRAM start address is currently at 2G (0x8000_0000). On the data path, MMINFRA remaps DRAM addresses by subtracting 2G, allowing SMMU to map DRAM addresses less than 2G. For example, if the DRAM start address 0x8000_0000 is mapped to IOVA=0x0, when GCE accesses IOVA=0x0, it must add a 2G offset to the address in the GCE instruction. MMINFRA will then see it as a data path (IOVA >= 2G) and subtract 2G, allowing GCE to access IOVA=0x0. Since the MMINFRA remap subtracting 2G is done in hardware and cannot be configured by software, the address of DRAM in GCE instruction must always add 2G to ensure proper access. After that, the shift functions do more than just shift addresses, so the APIs were renamed to cmdq_convert_gce_addr() and cmdq_revert_gce_addr(). This 2G adjustment is referred to as mminfra_offset in the CMDQ driver. CMDQ helper can get the mminfra_offset from the cmdq_mbox_priv of cmdq_pkt and add the mminfra_offset to the DRAM address in GCE instructions. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-01-19mailbox: mtk-cmdq: Add GCE hardware virtualization configurationJason-JH Lin
The GCE hardware virtualization configuration supports the isolation of GCE hardware resources across different OS environments. Each OS is treated as a virtual machine (VM) for GCE purposes. There are 6 VMs and 1 host VM. The host VM has main control over the GCE virtualization settings for all VMs. To properly access the GCE thread registers, it is necessary to configure access permissions for specific GCE threads assigned to different VMs. Currently, since only the host VM is being used, it is required to enable access permissions for all GCE threads for the host VM. There are 2 VM configurations: 1. VM_ID_MAP There are 4 registers to allocate 32 GCE threads across different VMs: VM_ID_MAP0 for threads 0-9, VM_ID_MAP1 for threads 10-19, VM_ID_MAP2 for threads 20-29, and VM_ID_MAP3 for threads 30-31. Each thread has a 3-bit configuration, where setting all bits to 1 configures the thread for the host VM. 2. VM_CPR_GSIZE It is used to allocate the CPR SRAM size to each VM. Each VM has 4-bit configuration, where setting bit 0-3 to configures the size of host VM. This setting must be configured before the VM configuration to prevent resource leakage. Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-13 20:48:44 +0000