summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2026-04-08spi: dt-bindings: renesas,rzv2h-rspi: Document RZ/G3L SoCBiju Das
Document RSPI IP found on the RZ/G3L SoC. The RSPI IP is compatible with the RZ/V2H RSPI IP, but has 2 clocks compared to 3 on RZ/V2H. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260408085418.18770-2-biju.das.jz@bp.renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-04-08Documentation: gpio: update the preferred method for using software node lookupBartosz Golaszewski
In its current version, the manual for converting of board files from using GPIO lookup tables to software nodes recommends leaving the software nodes representing GPIO controllers as "free-floating", not attached objects and relying on the matching of their names against the GPIO controller's name. This is an abuse of the software node API and makes it impossible to create fw_devlinks between GPIO suppliers and consumers in this case. We want to remove this behavior from GPIOLIB and to this end, work on converting all existing drivers to using "attached" software nodes. Except for a few corner-cases where board files define consumers depending on GPIO controllers described in firmware - where we need to reference a real firmware node from a software node - which requires a more complex approach, most board files can easily be converted to using propert firmware node lookup. Update the documentation to recommend attaching the GPIO chip's software nodes to the actual platform devices and show how to do it. Reviewed-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260403-doc-gpio-swnodes-v2-1-c705f5897b80@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-04-08Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/nextMarc Zyngier
* kvm-arm64/pkvm-protected-guest: (41 commits) : . : pKVM support for protected guests, implementing the very long : awaited support for anonymous memory, as the elusive guestmem : has failed to deliver on its promises despite a multi-year : effort. Patches courtesy of Will Deacon. From the initial cover : letter: : : "[...] this patch series implements support for protected guest : memory with pKVM, where pages are unmapped from the host as they are : faulted into the guest and can be shared back from the guest using pKVM : hypercalls. Protected guests are created using a new machine type : identifier and can be booted to a shell using the kvmtool patches : available at [2], which finally means that we are able to test the pVM : logic in pKVM. Since this is an incremental step towards full isolation : from the host (for example, the CPU register state and DMA accesses are : not yet isolated), creating a pVM requires a developer Kconfig option to : be enabled in addition to booting with 'kvm-arm.mode=protected' and : results in a kernel taint." : . KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm' drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL KVM: arm64: Rename PKVM_PAGE_STATE_MASK KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim KVM: arm64: Register 'selftest_vm' in the VM table KVM: arm64: Extend pKVM page ownership selftests to cover guest donation KVM: arm64: Add some initial documentation for pKVM KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler KVM: arm64: Introduce hypercall to force reclaim of a protected page KVM: arm64: Annotate guest donations with handle and gfn in host stage-2 KVM: arm64: Change 'pkvm_handle_t' to u16 KVM: arm64: Introduce host_stage2_set_owner_metadata_locked() ... Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-08Merge branch kvm-arm64/vgic-v5-ppi into kvmarm-master/nextMarc Zyngier
* kvm-arm64/vgic-v5-ppi: (40 commits) : . : Add initial GICv5 support for KVM guests, only adding PPI support : for the time being. Patches courtesy of Sascha Bischoff. : : From the cover letter: : : "This is v7 of the patch series to add the virtual GICv5 [1] device : (vgic_v5). Only PPIs are supported by this initial series, and the : vgic_v5 implementation is restricted to the CPU interface, : only. Further patch series are to follow in due course, and will add : support for SPIs, LPIs, the GICv5 IRS, and the GICv5 ITS." : . KVM: arm64: selftests: Add no-vgic-v5 selftest KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI Documentation: KVM: Introduce documentation for VGICv5 KVM: arm64: gic-v5: Probe for GICv5 device KVM: arm64: gic-v5: Set ICH_VCTLR_EL2.En on boot KVM: arm64: gic-v5: Introduce kvm_arm_vgic_v5_ops and register them KVM: arm64: gic-v5: Hide FEAT_GCIE from NV GICv5 guests KVM: arm64: gic: Hide GICv5 for protected guests KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5 KVM: arm64: gic-v5: Enlighten arch timer for GICv5 irqchip/gic-v5: Introduce minimal irq_set_type() for PPIs KVM: arm64: gic-v5: Initialise ID and priority bits when resetting vcpu KVM: arm64: gic-v5: Create and initialise vgic_v5 KVM: arm64: gic-v5: Support GICv5 interrupts with KVM_IRQ_LINE KVM: arm64: gic-v5: Implement direct injection of PPIs KVM: arm64: Introduce set_direct_injection irq_op KVM: arm64: gic-v5: Trap and mask guest ICC_PPI_ENABLERx_EL1 writes KVM: arm64: gic-v5: Check for pending PPIs KVM: arm64: gic-v5: Clear TWI if single task running ... Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-08Merge branch kvm-arm64/hyp-tracing into kvmarm-master/nextMarc Zyngier
* kvm-arm64/hyp-tracing: (40 commits) : . : EL2 tracing support, adding both 'remote' ring-buffer : infrastructure and the tracing itself, courtesy of : Vincent Donnefort. From the cover letter: : : "The growing set of features supported by the hypervisor in protected : mode necessitates debugging and profiling tools. Tracefs is the : ideal candidate for this task: : : * It is simple to use and to script. : : * It is supported by various tools, from the trace-cmd CLI to the : Android web-based perfetto. : : * The ring-buffer, where are stored trace events consists of linked : pages, making it an ideal structure for sharing between kernel and : hypervisor. : : This series first introduces a new generic way of creating remote events and : remote buffers. Then it adds support to the pKVM hypervisor." : . tracing: selftests: Extend hotplug testing for trace remotes tracing: Non-consuming read for trace remotes with an offline CPU tracing: Adjust cmd_check_undefined to show unexpected undefined symbols tracing: Restore accidentally removed SPDX tag KVM: arm64: avoid unused-variable warning tracing: Generate undef symbols allowlist for simple_ring_buffer KVM: arm64: tracing: add ftrace dependency tracing: add more symbols to whitelist tracing: Update undefined symbols allow list for simple_ring_buffer KVM: arm64: Fix out-of-tree build for nVHE/pKVM tracing tracing: selftests: Add hypervisor trace remote tests KVM: arm64: Add selftest event support to nVHE/pKVM hyp KVM: arm64: Add hyp_enter/hyp_exit events to nVHE/pKVM hyp KVM: arm64: Add event support to the nVHE/pKVM hyp and trace remote KVM: arm64: Add trace reset to the nVHE/pKVM hyp KVM: arm64: Sync boot clock with the nVHE/pKVM hyp KVM: arm64: Add trace remote for the nVHE/pKVM hyp KVM: arm64: Add tracing capability for the nVHE/pKVM hyp KVM: arm64: Support unaligned fixmap in the pKVM hyp KVM: arm64: Initialise hyp_nr_cpus for nVHE hyp ... Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-08pmdomain: Merge branch dt into nextUlf Hansson
Merge the immutable branch dt into next, to allow the updated DT bindings to be tested together with the pmdomain changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-04-08dt-bindings: power: qcom,rpmhpd: Add RPMh power domain for Hawi SoCFenglin Wu
Document the RPMh power domain for Hawi SoC, and add definitions for the new power domains which present in Hawi SoC: - RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display subsystem - RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics subsystem Also, add constants for new power domain levels that supported in Hawi SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0, TURBO_L1_0/1/2, TURBO_L1_0/1/2. Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-04-08Merge tag 'rust-timekeeping-for-v7.1' of ↵Miguel Ojeda
https://github.com/Rust-for-Linux/linux into rust-next Pull timekeeping updates from Andreas Hindborg: - Expand the example section in the 'HrTimer' documentation. - Mark the 'ClockSource' trait as unsafe to ensure valid values for 'ktime_get()'. - Add 'Delta::from_nanos()'. This is a back merge since the pull request has a newer base -- we will avoid that in the future. And, given it is a back merge, it happens to resolve the "subtle" conflict around '--remap-path-{prefix,scope}' that I discussed in linux-next [1], plus a few other common conflicts. The result matches what we did for next-20260407. The actual diffstat (i.e. using a temporary merge of upstream first) is: rust/kernel/time.rs | 32 ++++- rust/kernel/time/hrtimer.rs | 336 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 362 insertions(+), 6 deletions(-) Link: https://lore.kernel.org/linux-next/CANiq72kdxB=W3_CV1U44oOK3SssztPo2wLDZt6LP94TEO+Kj4g@mail.gmail.com/ [1] * tag 'rust-timekeeping-for-v7.1' of https://github.com/Rust-for-Linux/linux: hrtimer: add usage examples to documentation rust: time: make ClockSource unsafe trait rust/time: Add Delta::from_nanos()
2026-04-08Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get fixes from -rc7. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-04-07dt-bindings: net: wireless: add ath12k wifi device IPQ5424Raj Kumar Bhagat
Add the device-tree bindings for the ATH12K AHB wifi device IPQ5424. Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20260407-ath12k-ipq5424-v5-1-8e96aa660ec4@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-08mm: add gpu active/reclaim per-node stat counters (v2)Dave Airlie
While discussing memcg intergration with gpu memory allocations, it was pointed out that there was no numa/system counters for GPU memory allocations. With more integrated memory GPU server systems turning up, and more requirements for memory tracking it seems we should start closing the gap. Add two counters to track GPU per-node system memory allocations. The first is currently allocated to GPU objects, and the second is for memory that is stored in GPU page pools that can be reclaimed, by the shrinker. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org Cc: Andrew Morton <akpm@linux-foundation.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-07sched_ext: Documentation: Fix scx_bpf_move_to_local kfunc namefangqiurong
The correct kfunc name is scx_bpf_dsq_move_to_local(), not scx_bpf_move_to_local(). Fix the two references in the Scheduling Cycle section. Signed-off-by: fangqiurong <fangqiurong@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-04-07dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoCMukesh Ojha
Qualcomm Hawi SoC include apps smmu that implements arm,mmu-500, which is used to translate device-visible virtual addresses to physical addresses. Add compatible for these items. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-04-07landlock: Document fallocate(2) as another truncation corner caseGünther Noack
Reinforce the already stated policy that LANDLOCK_ACCESS_FS_TRUNCATE should always go hand in hand with LANDLOCK_ACCESS_FS_WRITE_FILE, as their meanings and enforcement overlap in counterintuitive ways. On many common file systems, fallocate(2) offers a way to shorten files as long as the file is opened for writing, side-stepping the LANDLOCK_ACCESS_FS_TRUNCATE right. Assisted-by: Gemini-CLI:gemini-3.1 Signed-off-by: Günther Noack <gnoack@google.com> Link: https://lore.kernel.org/r/20260401150911.1038072-1-gnoack@google.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-04-07landlock: Document FS access right for pathname UNIX socketsGünther Noack
Add LANDLOCK_ACCESS_FS_RESOLVE_UNIX to the example code, and explain it in the section about previous limitations. The bulk of the interesting flag documentation lives in the kernel header and is included in the Sphinx rendering. Cc: Justin Suess <utilityemal77@gmail.com> Cc: Mickaël Salaün <mic@digikod.net> Signed-off-by: Günther Noack <gnoack3000@gmail.com> Link: https://lore.kernel.org/r/20260327164838.38231-13-gnoack3000@gmail.com Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-04-07landlock: Control pathname UNIX domain socket resolution by pathGünther Noack
* Add a new access right LANDLOCK_ACCESS_FS_RESOLVE_UNIX, which controls the lookup operations for named UNIX domain sockets. The resolution happens during connect() and sendmsg() (depending on socket type). * Change access_mask_t from u16 to u32 (see below) * Hook into the path lookup in unix_find_bsd() in af_unix.c, using a LSM hook. Make policy decisions based on the new access rights * Increment the Landlock ABI version. * Minor test adaptations to keep the tests working. * Document the design rationale for scoped access rights, and cross-reference it from the header documentation. With this access right, access is granted if either of the following conditions is met: * The target socket's filesystem path was allow-listed using a LANDLOCK_RULE_PATH_BENEATH rule, *or*: * The target socket was created in the same Landlock domain in which LANDLOCK_ACCESS_FS_RESOLVE_UNIX was restricted. In case of a denial, connect() and sendmsg() return EACCES, which is the same error as it is returned if the user does not have the write bit in the traditional UNIX file system permissions of that file. The access_mask_t type grows from u16 to u32 to make space for the new access right. This also doubles the size of struct layer_access_masks from 32 byte to 64 byte. To avoid memory layout inconsistencies between architectures (especially m68k), pack and align struct access_masks [2]. Document the (possible future) interaction between scoped flags and other access rights in struct landlock_ruleset_attr, and summarize the rationale, as discussed in code review leading up to [3]. This feature was created with substantial discussion and input from Justin Suess, Tingmao Wang and Mickaël Salaün. Cc: Tingmao Wang <m@maowtm.org> Cc: Justin Suess <utilityemal77@gmail.com> Cc: Kuniyuki Iwashima <kuniyu@google.com> Suggested-by: Jann Horn <jannh@google.com> Link[1]: https://github.com/landlock-lsm/linux/issues/36 Link[2]: https://lore.kernel.org/all/20260401.Re1Eesu1Yaij@digikod.net/ Link[3]: https://lore.kernel.org/all/20260205.8531e4005118@gnoack.org/ Signed-off-by: Günther Noack <gnoack3000@gmail.com> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20260327164838.38231-5-gnoack3000@gmail.com [mic: Fix kernel-doc formatting, pack and align access_masks] Signed-off-by: Mickaël Salaün <mic@digikod.net>
2026-04-07dt-bindings: arm: cpus: Add Apple M3 CPU core compatiblesJanne Grunau
Add "apple,everest" compatible for the M3 performance core and "apple,sawtooth" for the M3 efficiency CPU core. These CPU cores are found on Apple Silicon SoCs M3 and M3 Pro, Max and Ultra. Signed-off-by: Janne Grunau <j@jannau.net> Link: https://patch.msgid.link/20260320-apple-m3-initial-devicetrees-v1-1-5842e1e393a8@jannau.net Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-04-07dt-bindings: display: lt8912b: Drop redundant endpoint propertiesKrzysztof Kozlowski
The "endpoint" node references video-interfaces.yaml schema with "unevaluatedProperties: false" which means that all properties from referenced schema apply. Listing some of them with ": true" is simply redundant and does not make this code easier to read. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260316134606.57070-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-04-07ASoC: Merge up v7.0-rc7Mark Brown
Merge tag 'v7.0-rc7' to get fixes that make my CI happier.
2026-04-07Documentation: tracing: Add PCI controller event documentationShawn Lin
The PCI controller tracepoint, pcie_ltssm_state_transition, monitors the LTSSM state transition and data rate changes for debugging purposes. Add documentation for it. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> [mani: added MAINTAINERS entry] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://patch.msgid.link/1774403912-210670-3-git-send-email-shawn.lin@rock-chips.com
2026-04-07hwmon: (yogafan) various markup improvementsRandy Dunlap
There are several places in yogafan.rst where it appears that lines are meant to be presented on their own but instead they are strung together due to the lack of markups. Fix these issues by: - using bullets where needed - indenting continuation lines of bulleted items - using a table where appropriate - using a literal block where appropriate Fixes: c67c248ca406 ("hwmon: (yogafan) Add support for Lenovo Yoga/Legion fan monitoring") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20260407052317.2097791-1-rdunlap@infradead.org Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-04-07docs: add an Assisted-by mention to submitting-patches.rstJonathan Corbet
We now require disclosure of the use of coding assistants, but our core submitting-patches document does not mention that. Add a brief mention with a pointer to Documentation/process/coding-assistants.rst Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <877bqtlzug.fsf@trenco.lwn.net>
2026-04-07ublk: enable UBLK_F_SHMEM_ZC feature flagMing Lei
Add UBLK_F_SHMEM_ZC (1ULL << 19) to the UAPI header and UBLK_F_ALL. Switch ublk_support_shmem_zc() and ublk_dev_support_shmem_zc() from returning false to checking the actual flag, enabling the shared memory zero-copy feature for devices that request it. Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://patch.msgid.link/20260331153207.3635125-4-ming.lei@redhat.com [axboe: ublk_buf_reg -> ublk_shmem_buf_reg errors] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-04-07dt-bindings: net: wireless: brcm: Add compatible for bcm43752Ronald Claveau
Add bcm43752 compatible with its bcm4329 compatible fallback. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20260327-add-bcm43752-compatible-v2-1-5b28e6637101@aliel.fr Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-07dt-bindings: chrome: Add cros-ec-ucsi compatibility to typec bindingJameson Thies
Chrome OS devices with discrete power delivery controllers (PDCs) allow the host to read port status and control port behavior through a USB Type-C Connector System Software (UCSI) interface with the embedded controller (EC). This uses a separate interface driver than other Chrome OS devices with a Type-C port manager in the EC FW. Those use a host command interface supported by cros-ec-typec. Add a cros-ec-ucsi compatibility string to the existing cros-ec-typec binding. Additionally, update maintainer list to reflect cros-ec-ucsi and cros-ec-typec driver maintainers. Signed-off-by: Jameson Thies <jthies@google.com> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Link: https://patch.msgid.link/20260403223357.1896403-2-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-07dt-bindings: opp-v2: Fix example 3 CPU reg valueVivian Wang
Example 3 is a dual-cluster example, meaning that the CPU nodes should have reg values 0x0, 0x1, 0x100, 0x101. The example incorrectly uses decimal 0, 1, 100, 101 instead, which seems unintended. Use the correct hexadecimal values. Even though the value doesn't change for the first two CPUs, 0 and 1 in example 3 are changed to 0x0 and 0x1 respectively for consistency. Other examples all have reg less than 10, so they have not been changed. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260403-dt-bindings-opp-v2-hex-cpu-reg-v1-1-38a4968ab515@iscas.ac.cn Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-04-07xfs: expose the number of open zones in sysfsChristoph Hellwig
Add a sysfs attribute for the current number of open zones so that it can be trivially read from userspace in monitoring or testing software. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Hans Holmberg <hans.holmberg@wdc.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org>
2026-04-07Merge v7.0-rc7 into drm-nextSimona Vetter
Thomas Zimmermann needs 2f42c1a61616 ("drm/ast: dp501: Fix initialization of SCU2C") for drm-misc-next. Conflicts: - drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c Just between e927b36ae18b ("drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()") and it's cherry-pick that confused git. - drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c Deleted in 6b0a6116286e ("drm/amd/pm: Unify version check in SMUv11") but some cherry-picks confused git. Same for v12/v14. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2026-04-07Merge tag 'icc-7.1-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: This pull request contains the interconnect changes for the 7.1-rc1 merge window. They are listed below: - New driver for Mahua SoC - New driver for Eliza SoC - Enable QoS support for QCS8300 and QCS615 SoCs - Add L3 cache scaling compatibles for SM8550 and Eliza SoCs - Fix multiple issues in the msm8974 driver - Fix kfree mismatch - Misc cleanups - Add maintainer entry for the interconnect KUnit tests Signed-off-by: Georgi Djakov <djakov@kernel.org> * tag 'icc-7.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc: (22 commits) MAINTAINERS: Add interconnect kunit test entry interconnect: debugfs: fix devm_kstrdup and kfree mismatch interconnect: qcom: msm8974: expand DEFINE_QNODE macros interconnect: qcom: msm8974: switch to the main icc-rpm driver interconnect: qcom: let platforms declare their bugginess interconnect: qcom: define OCMEM bus resource interconnect: qcom: icc-rpm: allow overwriting get_bw callback interconnect: qcom: drop unused is_on flag dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common dt-bindings: interconnect: qcom,msm8974: drop bus clocks interconnect: qcom: qcs615: enable QoS configuration dt-bindings: interconnect: qcom,qcs615-rpmh: add clocks property to enable QoS interconnect: qcom: Add Eliza interconnect provider driver dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Eliza SoC dt-bindings: interconnect: OSM L3: Add Eliza EPSS L3 compatible interconnect: qcom: De-acronymize SoC names dt-bindings: interconnect: qcom,glymur-rpmh: De-acronymize SoC name dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible interconnect: qcom: qcs8300: enable QoS configuration dt-bindings: interconnect: qcom,qcs8300-rpmh: add clocks property to enable QoS ...
2026-04-07Merge tag 'extcon-next-for-7.1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update extcon next for v7.1 Detailed description for this pull request: - Fix sysfs duplicate filename issue on extcon core : Adjust ida_free timing after device_unregister to prevent duplicate filename error when re-allocating id - Update NXP PTN5150 extcon driver and dt-binding document : Handle pending IRQ events during system resume : Allow "connector" node to present in devicetree : Add Type-C orientation switch support to correctly set orientation of multiplexer according to CC status : Support USB role switch via connector fwnode - Replace use of system_wq with system_percpu_wq on int3496 driver - Make typec-power-opmode optional on usbc-tusb320 driver : Prevent probe error when usb-c connector is configured in the DT without "typec-power-opmode" property * tag 'extcon-next-for-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: usbc-tusb320: Make typec-power-opmode optional extcon: ptn5150: Support USB role switch via connector fwnode extcon: ptn5150: Add Type-C orientation switch support dt-bindings: extcon: ptn5150: Allow "connector" node to present extcon: Fixed sysfs duplicate filename issue extcon: int3496: replace use of system_wq with system_percpu_wq extcon: ptn5150: handle pending IRQ events during system resume
2026-04-07docs: rust: general-information: use real exampleMiguel Ojeda
Currently the example in the documentation shows a version-based name for the Kconfig example: RUSTC_VERSION_MIN_107900 The reason behind it was to possibly avoid repetition in case several features used the same minimum. However, we ended up preferring to give them a descriptive name for each feature added even if that could lead to some repetition. In practice, the repetition has not happened so far, and even if it does at some point, it is not a big deal. Thus replace the example in the documentation with one of our current examples (after removing previous ones from the bump), to show how they actually look like, and in case someone `grep`s for it. In addition, it has the advantage that it shows the `RUSTC_HAS_*` pattern we follow in `init/Kconfig`, similar to the C side. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-31-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: general-information: simplify Kconfig exampleMiguel Ojeda
There is no need to use `def_bool y if <expr>` -- one can simply write `def_bool <expr>`. In fact, the simpler form is how we actually use them in practice in `init/Kconfig`. Thus simplify the example. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-30-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove GDB/Binutils mentionMiguel Ojeda
The versions provided nowadays by even a distribution like Debian Stable (and Debian Old Stable) are newer than those mentioned [1]. Thus remove the workaround. Note that the minimum binutils version in the kernel is still 2.30, so one could argue part of the note is still relevant, but it is unlikely a kernel developer using such an old binutils is enabling Rust on a modern kernel, especially when using distribution toolchains, e.g. the Rust minimum version is not satisfied by Debian Old Stable. So we are at the point where keeping the docs short and relevant for essentially everyone is probably the better trade-off. Link: https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1] Link: https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/ Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-29-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove Nix "unstable channel" noteMiguel Ojeda
Nix does not need the "unstable channel" note, since its packages are recent enough even in the stable channel [1][2]. Thus remove it to simplify the documentation. Link: https://search.nixos.org/packages?channel=25.11&query=rust [1] Link: https://search.nixos.org/packages?channel=25.11&query=bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-28-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove Gentoo "testing" noteMiguel Ojeda
Gentoo does not need the "testing" note, since its packages are recent enough even in the stable branch [1][2]. Thus remove it to simplify the documentation. Link: https://packages.gentoo.org/packages/dev-lang/rust [1] Link: https://packages.gentoo.org/packages/dev-util/bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-27-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection titleMiguel Ojeda
Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu 25.10 has [2][3]. We could update the title and the paragraph, but to simplify and to make it more consistent with the other distributions' sections, let's instead just remove that title. It will also reduce the differences later on to keep it updated. Eventually, when we remove the remaining subsection for older LTSs, Ubuntu should be a small section like the other distributions. Thus remove the title and add the mention of Ubuntu 26.04 LTS. Link: https://documentation.ubuntu.com/release-notes/26.04/schedule/#resolute-raccoon-schedule [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all&section=all [2] Link: https://packages.ubuntu.com/search?keywords=bindgen&searchon=names&exact=1&suite=all&section=all [3] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-26-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: update minimum Ubuntu versionMiguel Ojeda
Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest supported one. Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust given the minimum bump -- they provide 1.85.1 [2]. Thus update it. Link: https://ubuntu.com/about/release-cycle [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all&section=all [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-25-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: update Ubuntu versioned packagesMiguel Ojeda
Now that the minimum supported Rust version is bumped, bump the versioned Rust packages [1][2][3][4] to that version for Ubuntu in the Quick Start guide. In addition, add "may" to the `RUST_LIB_SRC` line since it does not look like it is needed from a quick test in a Ubuntu 24.04 LTS container. Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [1] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [2] Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [3] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [4] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-24-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: openSUSE provides `rust-src` package nowadaysMiguel Ojeda
Both openSUSE Tumbleweed and Slowroll provide the `rust-src` package nowadays [1]. Thus remove the version-specific one from the Quick Start guide. Link: https://software.opensuse.org/package/rust-src?search_term=rust-src [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-23-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)Miguel Ojeda
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's `bindgen` versions as our minimum supported version. Debian Trixie was released with `bindgen` 0.71.1, which it still uses to this day [2]. Debian Trixie's release happened on 2025-08-09 [3], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already unsupported Ubuntu 25.04 had it), and they also provide versioned packages with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://packages.debian.org/trixie/bindgen [2] Link: https://www.debian.org/releases/trixie/ [3] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5] Acked-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)Miguel Ojeda
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version. Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1). Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those. Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION` tests can also be updated, but there are no suitable ones to simplify. Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2] Link: https://packages.debian.org/trixie/rustc [3] Link: https://www.debian.org/releases/trixie/ [4] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5] Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6] Acked-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Benno Lossin <lossin@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260405235309.418950-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrlRichard Acayan
Add the pin controller for the audio Low-Power Island (LPI) on SDM670. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-04-07dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs propertyRichard Acayan
There can be reserved GPIOs on the LPASS LPI pin controller to possibly control sensors. Add the property for reserved GPIOs so they can be avoided appropriately. Adapted from the same entry in qcom,tlmm-common.yaml. Signed-off-by: Richard Acayan <mailingradian@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-04-06dt-bindings: nfc: nxp,nci: Document PN557 compatibleDavid Heidelberg
The PN557 uses the same hardware as the PN553 but ships with firmware compliant with NCI 2.0. Document PN557 as a compatible device. Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260403-oneplus-nfc-v3-1-fbdce57d63c1@ixit.cz Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-06psp: add missing device stats to get-stats reply attributesDaniel Zahka
Commit f05d26198cf2 ("psp: add stats from psp spec to driver facing api") added device statistics (rx-packets, rx-bytes, rx-auth-fail, rx-error, rx-bad, tx-packets, tx-bytes, tx-error) to the stats attribute-set but did not add them to the get-stats operation reply attributes. The kernel reports these attributes in the reply, so list them in the spec to match. Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Acked-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260403-psp-yaml-fix-v1-1-dacee0663903@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-06sched_ext: Documentation: Add ops.dequeue() to task lifecycleAndrea Righi
Document ops.dequeue() in the sched_ext task lifecycle now that its semantics are well-defined. Also update the pseudo-code to use task_is_runnable() consistently and clarify the case where ops.dispatch() does not refill the time slice. Signed-off-by: Andrea Righi <arighi@nvidia.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-04-06Merge tag 'soc-fixes-7.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "The largest part here are devicetree fixes for Qualcomm, and NXP i.MX, addressing a few regressions and incorrect settings in board and SoC pecific dts files. The largest single commits are a revert of a cleanup patch for i.MX that caused regressions for the NAND flash controller and a fixup for an incomplete cleanup of the PCIe controller on Qualcomm platforms that broke because the state was left incompatible with both the old and new behavior. On the Rockchips, Hisilicon, Renesas, Allwinner and AT91 platforms, only a single simple dts bugfix each was added since the last round of fixes. On the SoC specific device drivers, everything is relatively harmless: three reset controller driver fixes, a compatibility for fix ASpeed soc ID, and error handling fixes for Qualcomm and Microchip. One regression fix on Qualcomm addresses a problem with a previous fix for DisplayPort alt mode" * tag 'soc-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits) arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration dt-bindings: display/msm: qcm2290-mdss: Fix missing ranges in example firmware: microchip: fail auto-update probe if no flash found arm64: dts: renesas: sparrow-hawk: Reserve first 128 MiB of DRAM arm64: dts: qcom: agatti: Fix IOMMU DT properties dt-bindings: media: venus: Fix iommus property dt-bindings: display: msm: qcm2290-mdss: Fix iommus property arm64: dts: allwinner: sun55i: Fix r-spi DMA reset: spacemit: k3: Decouple composite reset lines reset: gpio: fix double free in reset_add_gpio_aux_device() error path ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB arm64: dts: hisilicon: hi3798cv200: Add missing dma-ranges arm64: dts: hisilicon: poplar: Correct PCIe reset GPIO polarity reset: rzg2l-usbphy-ctrl: Fix malformed MODULE_AUTHOR string soc: microchip: mpfs-mss-top-sysreg: Fix resource leak on driver unbind soc: microchip: mpfs-control-scb: Fix resource leak on driver unbind soc: qcom: pmic_glink_altmode: Fix TBT->SAFE->!TBT transition arm64: dts: qcom: monaco: Reserve full Gunyah metadata region arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V Revert "arm64: dts: imx8mq-librem5: Set the DVS voltages lower" ...
2026-04-06PCI/TPH: Pass ACPI Processor UID to Cache Locality _DSMChengwen Feng
pcie_tph_get_cpu_st() uses the Query Cache Locality Features _DSM [1] to retrieve the TPH Steering Tag for memory associated with the CPU identified by its "cpu_uid" parameter, a Linux logical CPU ID. The _DSM requires an ACPI Processor UID, which pcie_tph_get_cpu_st() previously assumed was the same as the Linux logical CPU ID. This is true on x86 but not on arm64, so pcie_tph_get_cpu_st() returned the wrong Steering Tag, resulting in incorrect TPH functionality on arm64. Convert the Linux logical CPU ID to the ACPI Processor UID with acpi_get_cpu_uid() before passing it to the _DSM. Additionally, rename the pcie_tph_get_cpu_st() parameter from "cpu_uid" to "cpu" to reflect that it represents a logical CPU ID (not an ACPI Processor UID). [1] According to ECN_TPH-ST_Revision_20200924 (https://members.pcisig.com/wg/PCI-SIG/document/15470), the input is defined as: "If the target is a processor, then this field represents the ACPI Processor UID of the processor as specified in the MADT. If the target is a processor container, then this field represents the ACPI Processor UID of the processor container as specified in the PPTT." Fixes: d2e8a34876ce ("PCI/TPH: Add Steering Tag support") Signed-off-by: Chengwen Feng <fengchengwen@huawei.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260401081640.26875-9-fengchengwen@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-06dt-bindings: remoteproc: qcom,milos-pas: Document Eliza ADSPAbel Vesa
Since the devicetree bindings are exactly the same between Eliza ADSP and Milos ADSP, reuse the existing Milos schema, just add the Eliza specific ADSP compatible. Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260327-eliza-remoteproc-adsp-v1-1-1c46c5e5f809@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-06dt-bindings: remoteproc: qcom: Drop types for firmware-nameShawn Guo
The type of firmware-name is already defined by core schemas. Drop it from individual bindings that have either a redundant definition or an override as string type. For the later cases, constrain the number of expected firmware names to 1. Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260309123357.1911586-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>