summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2026-03-03KVM: x86: Use local MMIO fragment variable to clean up emulator_read_write()Sean Christopherson1-6/+5
Grab the MMIO fragment used by emulator_read_write() to initiate an exit to userspace in a local variable to make the code easier to read. No functional change intended. Tested-by: Tom Lendacky <thomas.lendacky@gmail.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260225012049.920665-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86: Trace unsatisfied MMIO reads on a per-page basisSean Christopherson1-1/+8
Invoke the "unsatisfied MMIO reads" when KVM first detects that a particular access "chunk" requires an exit to userspace instead of tracing the entire access at the time KVM initiates the exit to userspace. I.e. precisely trace the first and/or second fragments of a page split instead of tracing the entire access, as the GPA could be wrong on a page split case. Leave the completion tracepoint alone, at least for now, as fixing the completion path would incur significantly complexity to track exactly which fragment(s) of the overall access actually triggered MMIO, but add a comment that the tracing for completed reads in is technically wrong. Tested-by: Tom Lendacky <thomas.lendacky@gmail.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260225012049.920665-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86: Open code handling of completed MMIO reads in emulator_read_write()Sean Christopherson2-17/+29
Open code the handling of completed MMIO reads instead of using an ops hook, as burying the logic behind a (likely RETPOLINE'd) indirect call, and with an unintuitive name, makes relatively straightforward code hard to comprehend. Opportunistically add comments to explain the dependencies between the emulator's mem_read cache and the MMIO read completion logic, as it's very easy to overlook the cache's role in getting the read data into the correct destination. No functional change intended. Tested-by: Tom Lendacky <thomas.lendacky@gmail.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260225012049.920665-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86: Use scratch field in MMIO fragment to hold small write valuesSean Christopherson1-1/+13
When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value. This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, *and* both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable. The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data. ================================================================== BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984 CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0xbe/0xfd print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 check_memory_region+0xfd/0x1f0 memcpy+0x20/0x60 complete_emulated_mmio+0x305/0x420 kvm_arch_vcpu_ioctl_run+0x63f/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscall_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720 The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by overwrite the data value with garbage. Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *all* reads are buffered through the mem_read cache. Note! Using the scratch field for reads is not only unnecessary, it's also extremely difficult to handle correctly. As above, KVM buffers all reads through the mem_read cache, and heavily relies on that behavior when re-emulating the instruction after a userspace MMIO read exit. If a read splits a page, the first page is NOT an MMIO page, and the second page IS an MMIO page, then the MMIO fragment needs to point at _just_ the second chunk of the destination, i.e. its position in the mem_read cache. Taking the "obvious" approach of copying the fragment value into the destination when re-emulating the instruction would clobber the first chunk of the destination, i.e. would clobber the data that was read from guest memory. Fixes: f78146b0f923 ("KVM: Fix page-crossing MMIO") Suggested-by: Yashu Zhang <zhangjiaji1@huawei.com> Reported-by: Yashu Zhang <zhangjiaji1@huawei.com> Closes: https://lore.kernel.org/all/369eaaa2b3c1425c85e8477066391bc7@huawei.com Cc: stable@vger.kernel.org Tested-by: Tom Lendacky <thomas.lendacky@gmail.com> Tested-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Link: https://patch.msgid.link/20260225012049.920665-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86: Ignore cpuid faulting in SMMJim Mattson2-4/+5
The Intel Virtualization Technology FlexMigration Application Note says, "When CPUID faulting is enabled, all executions of the CPUID instruction outside system-management mode (SMM) cause a general-protection exception (#GP(0)) if the current privilege level (CPL) is greater than 0." Always allow the execution of CPUID in SMM. Fixes: db2336a80489 ("KVM: x86: virtualize cpuid faulting") Signed-off-by: Jim Mattson <jmattson@google.com> Link: https://patch.msgid.link/20260210234613.1383279-1-jmattson@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2Yosry Ahmed1-0/+1
After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. int_state is also written by the CPU, specifically bit 0 (i.e. SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites what KVM_SET_NESTED_STATE restored in int_state). However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow). Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02() to avoid this problem. With that, KVM_SET_NESTED_STATE restores the correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it would overwrite it with the same value. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260225005950.3739782-3-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: nSVM: Sync NextRIP to cached vmcb12 after VMRUN of L2Yosry Ahmed1-0/+10
After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state. NextRIP is also written by the CPU (in some cases) after VMRUN, but is not sync'd to the cached vmcb12. As a result, it is corrupted after save/restore (replaced by the original value written by L1 on nested VMRUN). This could cause problems for both KVM (e.g. when injecting a soft IRQ) or L1 (e.g. when using NextRIP to advance RIP after emulating an instruction). Fix this by sync'ing NextRIP to the cache after VMRUN of L2, but only after completing interrupts (not in nested_sync_control_from_vmcb02()), as KVM may update NextRIP (e.g. when re-injecting a soft IRQ). Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Co-developed-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260225005950.3739782-2-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: nSVM: Ensure AVIC is inhibited when restoring a vCPU to guest modeYosry Ahmed1-0/+3
On nested VMRUN, KVM ensures AVIC is inhibited by requesting KVM_REQ_APICV_UPDATE, triggering a check of inhibit reasons, finding APICV_INHIBIT_REASON_NESTED, and disabling AVIC. However, when KVM_SET_NESTED_STATE is performed on a vCPU not in guest mode with AVIC enabled, KVM_REQ_APICV_UPDATE is not requested, and AVIC is not inhibited. Request KVM_REQ_APICV_UPDATE in the KVM_SET_NESTED_STATE path if AVIC is active, similar to the nested VMRUN path. Fixes: f44509f849fe ("KVM: x86: SVM: allow AVIC to co-exist with a nested guest running") Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry@kernel.org> Link: https://patch.msgid.link/20260224225017.3303870-1-yosry@kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86: Check for injected exceptions before queuing a debug exceptionYosry Ahmed1-1/+1
On KVM_SET_GUEST_DEBUG, if a #DB or #BP is injected with KVM_GUESTDBG_INJECT_DB or KVM_GUESTDBG_INJECT_BP, KVM fails with -EBUSY if there is an existing pending exception. This was introduced in commit 4f926bf29186 ("KVM: x86: Polish exception injection via KVM_SET_GUEST_DEBUG") to avoid a warning in kvm_queue_exception(), presumably to avoid overriding a pending exception. This added another (arguably nice) property, if there's a pending exception, KVM_SET_GUEST_DEBUG cannot cause a #DF or triple fault. However, if an exception is injected, KVM_SET_GUEST_DEBUG will cause a #DF or triple fault in the guest, as kvm_multiple_exception() combines them. Check for both pending and injected exceptions for KVM_GUESTDBG_INJECT_DB and KVM_GUESTDBG_INJECT_BP, to avoid accidentally injecting a #DB or triple fault. Signed-off-by: Yosry Ahmed <yosry@kernel.org> base-commit: a68a4bbc5b9ce5b722473399f05cb05217abaee8 Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: Isolate apicv_update_lock and apicv_nr_irq_window_req in a cachelineSean Christopherson1-1/+11
Force apicv_update_lock and apicv_nr_irq_window_req to reside in their own cacheline to avoid generating significant contention due to false sharing when KVM is contantly creating IRQ windows. E.g. apicv_inhibit_reasons is read on every VM-Enter; disabled_exits is read on page faults, on PAUSE exits, if a vCPU is scheduled out, etc.; kvmclock_offset is read every time a vCPU needs to refresh kvmclock, and so on and so forth. Isolating the write-mostly fields from all other (read-mostly) fields improves performance by 7-8% when running netperf TCP_RR between two guests on the same physical host when using an in-kernel PIT in re-inject mode. Reported-by: Naveen N Rao (AMD) <naveen@kernel.org> Closes: https://lore.kernel.org/all/yrxhngndj37edud6tj5y3vunaf7nirwor4n63yf4275wdocnd3@c77ujgialc6r Tested-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260123224514.2509129-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: SVM: Optimize IRQ window inhibit handlingSean Christopherson1-1/+25
IRQ windows represent times during which an IRQ can be injected into a vCPU, and thus represent times when a vCPU is running with RFLAGS.IF=1 and GIF enabled (TPR/PPR don't matter since KVM controls interrupt injection and it only injects one interrupt at a time). On SVM, when emulating the local APIC (i.e., AVIC disabled), KVM detects IRQ windows by injecting a dummy virtual interrupt through VMCB.V_IRQ and intercepting virtual interrupts (INTERCEPT_VINTR). This intercept triggers as soon as the guest enables interrupts and is about to take the dummy interrupt, at which point the actual interrupt can be injected through VMCB.EVENTINJ. When AVIC is enabled, VMCB.V_IRQ is ignored by the hardware and so detecting IRQ windows requires AVIC to be inhibited. However, this is only necessary for ExtINTs since all other interrupts can be injected either by directly setting IRR in the APIC backing page and letting the AVIC hardware inject the interrupt into the guest, or via VMCB.V_NMI for NMIs. If AVIC is enabled but inhibited for some other reason, KVM has to request for IRQ window inhibits every time it has to inject an interrupt into the guest. This is because APICv inhibits are dynamic in nature, so KVM has to be sure that AVIC is inhibited for purposes of discovering an IRQ window even if the other inhibit is cleared in the meantime. This is particularly problematic with APICV_INHIBIT_REASON_PIT_REINJ which stays set throughout the life of the guest and results in KVM rapidly toggling IRQ window inhibit resulting in contention on apicv_update_lock. Address this by setting and clearing APICV_INHIBIT_REASON_PIT_REINJ lazily: if some other inhibit reason is already set, just increment the IRQ window request count and do not update apicv_inhibit_reasons immediately. If any other inhibit reason is set/cleared in the meantime, re-evaluate APICV_INHIBIT_REASON_PIT_REINJ by checking the IRQ window request count and update apicv_inhibit_reasons appropriately. Otherwise, just the IRQ window request count is incremented/decremented each time an IRQ window is requested. This reduces much of the contention on the apicv_update_lock semaphore and does away with much of the performance degradation. Co-developed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Co-developed-by: Naveen N Rao (AMD) <naveen@kernel.org> Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org> Tested-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260123224514.2509129-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: SVM: Fix IRQ window inhibit handling across multiple vCPUsSean Christopherson4-12/+63
IRQ window inhibits can be requested by multiple vCPUs at the same time for injecting interrupts meant for different vCPUs. However, AVIC inhibition is VM-wide and hence it is possible for the inhibition to be cleared prematurely by the first vCPU that obtains the IRQ window even though a second vCPU is still waiting for its IRQ window. This is likely not a functional issue since the other vCPU will again see that interrupts are pending to be injected (due to KVM_REQ_EVENT), and will again request for an IRQ window inhibition. However, this can result in AVIC being rapidly toggled resulting in high contention on apicv_update_lock and degrading performance of the guest. Address this by maintaining a VM-wide count of the number of vCPUs that have requested for an IRQ window. Set/clear the inhibit reason when the count transitions between 0 and 1. This ensures that the inhibit reason is not cleared as long as there are some vCPUs still waiting for an IRQ window. Co-developed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Co-developed-by: Naveen N Rao (AMD) <naveen@kernel.org> Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org> Tested-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260123224514.2509129-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: SVM: Fix clearing IRQ window inhibit with nested guestsSean Christopherson1-14/+14
Clearing IRQ window inhibit today relies on interrupt window interception, but that is not always reachable when nested guests are involved. If L1 is intercepting IRQs, then interrupt_window_interception() will never be reached while L2 is active, because the only reason KVM would set the V_IRQ intercept in vmcb02 would be on behalf of L1, i.e. because of vmcb12. svm_clear_vintr() always operates on (at least) vmcb01, and VMRUN unconditionally sets GIF=1, which means that enter_svm_guest_mode() will always do svm_clear_vintr() via svm_set_gif(svm, true). I.e. KVM will keep the VM-wide inhibit set until control transfers back to L1 *and* an interrupt window is triggered. If L1 is not intercepting IRQs, KVM may immediately inject L1's ExtINT into L2 if IRQs are enabled in L2 without taking an interrupt window interception. Address this by clearing the IRQ window inhibit when KVM actually injects an interrupt and there are no further injectable interrupts. That way, if L1 isn't intercepting IRQs, KVM will drop the inhibit as soon as an interrupt is injected into L2. And if L1 is intercepting IRQs, KVM will keep the inhibit until the IRQ is injected into L2. So, AVIC won't be left inhibited. Note, somewhat blindly invoking kvm_clear_apicv_inhibit() is both wrong and suboptimal. If the IRQWIN inhibit isn't set, then the vCPU will unnecessarily take apicv_update_lock for write. And if a _different_ vCPU has an injectable IRQ, clearing IRQWIN may block that vCPU's ability to inject its IRQ. Defer fixing both issues to a future commit, as fixing one problem without also fixing the other would also leave KVM in a temporarily bad state, as would fixing both issues without fixing _this_ bug. I.e. it's not feasible to fix each bug independently without there being some remaining flaw in KVM. Co-developed-by: Naveen N Rao (AMD) <naveen@kernel.org> Signed-off-by: Naveen N Rao (AMD) <naveen@kernel.org> Tested-by: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260123224514.2509129-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: SVM: Mark module parameters as __ro_after_init for security and performanceLi RongQing3-22/+22
SVM module parameters such as avic, sev_enabled, npt_enabled, and pause_filter_thresh are configured exclusively during initialization (via kernel command line) and remain constant throughout runtime. Additionally, sev_supported_vmsa_features and svm_gp_erratum_intercept, while not exposed as module parameters, share the same initialization pattern and runtime constancy. Mark these variables with '__ro_after_init' to: - Harden against accidental or malicious runtime modification - Enable compiler and CPU optimizations (improved caching, branch prediction) - Align with kernel security best practices for init-only configuration The exception is 'iopm_base', which retains '__read_mostly' as it requires updates during module unloading. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Link: https://patch.msgid.link/20260202095004.1765-1-lirongqing@baidu.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: SVM: Mark module parameters as __ro_after_init for security and performanceLi RongQing3-22/+22
SVM module parameters such as avic, sev_enabled, npt_enabled, and pause_filter_thresh are configured exclusively during initialization (via kernel command line) and remain constant throughout runtime. Additionally, sev_supported_vmsa_features and svm_gp_erratum_intercept, while not exposed as module parameters, share the same initialization pattern and runtime constancy. Mark these variables with '__ro_after_init' to: - Harden against accidental or malicious runtime modification - Enable compiler and CPU optimizations (improved caching, branch prediction) - Align with kernel security best practices for init-only configuration The exception is 'iopm_base', which retains '__read_mostly' as it requires updates during module unloading. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Li RongQing <lirongqing@baidu.com> Link: https://patch.msgid.link/20260202095004.1765-1-lirongqing@baidu.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: nSVM: Mark all of vmcb02 dirty when restoring nested stateYosry Ahmed1-0/+6
When restoring a vCPU in guest mode, any state restored before KVM_SET_NESTED_STATE (e.g. KVM_SET_SREGS) will mark the corresponding dirty bits in vmcb01, as it is the active VMCB before switching to vmcb02 in svm_set_nested_state(). Hence, mark all fields in vmcb02 dirty in svm_set_nested_state() to capture any previously restored fields. Fixes: cc440cdad5b7 ("KVM: nSVM: implement KVM_GET_NESTED_STATE and KVM_SET_NESTED_STATE") CC: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260210010806.3204289-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: VMX: Use ASM_INPUT_RM in __vmcs_writelUros Bizjak1-1/+1
Use the ASM_INPUT_RM macro for VMCS write operation in vmx_ops.h to work around clang problems with "rm" asm constraint. clang seems to always chose the memory input, while it is almost always the worst choice. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260211102928.100944-2-ubizjak@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: VMX: Drop obsolete branch hint prefixes from inline asmUros Bizjak1-3/+0
Remove explicit branch hint prefixes (.byte 0x2e / 0x3e) from VMX inline assembly sequences. These prefixes (CS/DS segment overrides used as branch hints on very old x86 CPUs) have been ignored by modern processors for a long time. Keeping them provides no measurable benefit and only enlarges the generated code. No functional change intended. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://patch.msgid.link/20260211102928.100944-1-ubizjak@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86/pmu: annotate struct kvm_x86_pmu_event_filter with __counted_by()Carlos López2-2/+2
struct kvm_x86_pmu_event_filter has a flexible array member, so annotate it with the field that describes the amount of entries in such array. Opportunistically replace the open-coded array size calculation with flex_array_size() when copying the array portion of the struct from userspace. Signed-off-by: Carlos López <clopez@suse.de> Link: https://patch.msgid.link/20260212140556.3883030-2-clopez@suse.de Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03KVM: x86: Zero-initialize temporary fxregs_state buffers in FXSAVE emulationUros Bizjak1-2/+2
Explicitly zero-initialize stack-allocated struct fxregs_state variables in em_fxsave() and fxregs_fixup() to ensure all padding and unused fields are cleared before use. Both functions declare temporary fxregs_state buffers that may be partially written by fxsave. Although the emulator copies only the architecturally defined portion of the state to userspace, any padding or otherwise untouched bytes in the structure can remain uninitialized. This can lead to the use of uninitialized stack data and may trigger KMSAN reports. In the worst case, it could result in leaking stack contents if such bytes are ever exposed. No functional change intended. Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://patch.msgid.link/20260212212457.24483-1-ubizjak@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-03arm64: dts: imx93-phyboard-segin: Add peb-av-02 overlayAndrej Picej2-0/+148
Add overlay for Audio-Video module PEB-AV-02. Add support for panel display, capacitive touchscreen and backlight. The pwm-backlight uses the GPIO based PWM implementation for now. Switch to the FlexIO PWM support once available. Signed-off-by: Andrej Picej <andrej.picej@norik.com> [rework commit message, use local regulator, remove compatible] Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Christian Hemp <c.hemp@phytec.de> [m.felsch@pengutronix.de: cleanup downstream commit] Tested-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: freescale: Add the GOcontroll Moduline MiniMaud Spierings2-0/+688
The Moduline Mini is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. Features: - up to 4 Moduline IO modules - 2 CAN busses - 1 Ethernet - 4 RGB leds - 1 3D accelerometer - optional Wi-Fi/Bluetooth - optional 4G/GPS Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: freescale: Add the GOcontroll Moduline IVMaud Spierings2-0/+800
The Moduline IV is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. Features: - up to 8 Moduline IO modules - 4 CAN busses - 1 LIN bus - 1 Ethernet - 4 RGB leds - optional Wi-Fi/Bluetooth - optional 4G/GPS Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COMMaud Spierings1-0/+444
The Ka-Ro Electronics tx8m-1610 is a COM based on the imx8mm SOC. It has 1 GB of ram and 4 GB of eMMC storage on board. Add it to enable boards based on this module Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: imx8mm: Add pinctrl config definitionsMaud Spierings1-0/+33
Currently to configure each IOMUXC_SW_PAD_CTL_PAD the raw value of this register is written in the dts, these values are not obvious. Add defines which describe the fields of this register which can be or-ed together to produce readable settings. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: freescale: add NXP FRDM-IMX91S board supportYanan Yang2-0/+770
Add DeviceTree support for the NXP FRDM-IMX91S development board based on the i.MX91 SoC. FRDM-IMX91S is a cost-optimized variant of FRDM-IMX91 and differs in memory, storage, Ethernet, and PMIC configuration: - 512MB LPDDR4 (FRDM-IMX91 uses 1GB) - 256MB FlexSPI-NAND (FRDM-IMX91 uses 8GB eMMC) - Single GbE port (FRDM-IMX91 has dual GbE) - PMIC PF9453 (FRDM-IMX91 uses PCA9451A) This DT enables: - ADC1 - UART1 and UART5 - I2C bus and children nodes - USB and related nodes - uSDHC1 and uSDHC2 - FlexSPI NAND flash - Watchdog3 - Ethernet (eqos) - FlexCAN - MQS Link: https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91S (FRDM-IMX91S board page) Link: https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91 (FRDM-IMX91 board page) Co-developed-by: Lei Xu <lei.xu@nxp.com> Signed-off-by: Lei Xu <lei.xu@nxp.com> Co-developed-by: Xiaofeng Wei <xiaofeng.wei@nxp.com> Signed-off-by: Xiaofeng Wei <xiaofeng.wei@nxp.com> Signed-off-by: Yanan Yang <yanan.yang@nxp.com> Tested-by: Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: imx91-11x11-evk: Add usdhc3 for SDIO WiFi supportSherry Sun1-0/+96
Add usdhc3 to support M.2 SDIO WiFi on i.MX91 11x11 EVK board. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: imx8mp-evk: Add usdhc1 for SDIO WiFi supportSherry Sun1-1/+60
Add usdhc1 to support M.2 SDIO WiFi on i.MX8MP EVK board. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02KVM: x86: Defer non-architectural deliver of exception payload to userspace readSean Christopherson1-23/+39
When attempting to play nice with userspace that hasn't enabled KVM_CAP_EXCEPTION_PAYLOAD, defer KVM's non-architectural delivery of the payload until userspace actually reads relevant vCPU state, and more importantly, force delivery of the payload in *all* paths where userspace saves relevant vCPU state, not just KVM_GET_VCPU_EVENTS. Ignoring userspace save/restore for the moment, delivering the payload before the exception is injected is wrong regardless of whether L1 or L2 is running. To make matters even more confusing, the flaw *currently* being papered over by the !is_guest_mode() check isn't even the same bug that commit da998b46d244 ("kvm: x86: Defer setting of CR2 until #PF delivery") was trying to avoid. At the time of commit da998b46d244, KVM didn't correctly handle exception intercepts, as KVM would wait until VM-Entry into L2 was imminent to check if the queued exception should morph to a nested VM-Exit. I.e. KVM would deliver the payload to L2 and then synthesize a VM-Exit into L1. But the payload was only the most blatant issue, e.g. waiting to check exception intercepts would also lead to KVM incorrectly escalating a should-be-intercepted #PF into a #DF. That underlying bug was eventually fixed by commit 7709aba8f716 ("KVM: x86: Morph pending exceptions to pending VM-Exits at queue time"), but in the interim, commit a06230b62b89 ("KVM: x86: Deliver exception payload on KVM_GET_VCPU_EVENTS") came along and subtly added another dependency on the !is_guest_mode() check. While not recorded in the changelog, the motivation for deferring the !exception_payload_enabled delivery was to fix a flaw where a synthesized MTF (Monitor Trap Flag) VM-Exit would drop a pending #DB and clobber DR6. On a VM-Exit, VMX CPUs save pending #DB information into the VMCS, which is emulated by KVM in nested_vmx_update_pending_dbg() by grabbing the payload from the queue/pending exception. I.e. prematurely delivering the payload would cause the pending #DB to not be recorded in the VMCS, and of course, clobber L2's DR6 as seen by L1. Jumping back to save+restore, the quirked behavior of forcing delivery of the payload only works if userspace does KVM_GET_VCPU_EVENTS *before* CR2 or DR6 is saved, i.e. before KVM_GET_SREGS{,2} and KVM_GET_DEBUGREGS. E.g. if userspace does KVM_GET_SREGS before KVM_GET_VCPU_EVENTS, then the CR2 saved by userspace won't contain the payload for the exception save by KVM_GET_VCPU_EVENTS. Deliberately deliver the payload in the store_regs() path, as it's the least awful option even though userspace may not be doing save+restore. Because if userspace _is_ doing save restore, it could elide KVM_GET_SREGS knowing that SREGS were already saved when the vCPU exited. Link: https://lore.kernel.org/all/20200207103608.110305-1-oupton@google.com Cc: Yosry Ahmed <yosry.ahmed@linux.dev> Cc: stable@vger.kernel.org Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Tested-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260218005438.2619063-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-02KVM: nSVM: Use vcpu->arch.cr2 when updating vmcb12 on nested #VMEXITYosry Ahmed1-1/+1
KVM currently uses the value of CR2 from vmcb02 to update vmcb12 on nested #VMEXIT. This value is incorrect in some cases, causing L1 to run L2 with a corrupted CR2. This could lead to segfaults or data corruption if L2 is in the middle of handling a #PF and reads a corrupted CR2. Use the correct value in vcpu->arch.cr2 instead. The value in vcpu->arch.cr2 is sync'd to vmcb02 shortly before a VMRUN of L2, and sync'd back to vcpu->arch.cr2 shortly after. The value are only out-of-sync in two cases: after save+restore, and after a #PF is injected into L2. In either case, if a #VMEXIT to L1 is synthesized before L2 runs, using the value in vmcb02 would be incorrect. After save+restore, the value of CR2 is restored by KVM_SET_SREGS into vcpu->arch.cr2. It is not reflect in vmcb02 until a VMRUN of L2. Before that, it holds whatever was in vmcb02 before restore, which would be zero on a new vCPU that never ran nested. If a #VMEXIT to L1 is synthesized before L2 ever runs, using vcpu->arch.cr2 to update vmcb12 is the right thing to do. The #PF injection case is more nuanced. Although the APM is a bit unclear about when CR2 is written during a #PF, the SDM is more clear: Processors update CR2 whenever a page fault is detected. If a second page fault occurs while an earlier page fault is being delivered, the faulting linear address of the second fault will overwrite the contents of CR2 (replacing the previous address). These updates to CR2 occur even if the page fault results in a double fault or occurs during the delivery of a double fault. KVM injecting the exception surely counts as the #PF being "detected". More importantly, when an exception is injected into L2 at the time of a synthesized #VMEXIT, KVM updates exit_int_info in vmcb12 accordingly, such that an L1 hypervisor can re-inject the exception. If CR2 is not written at that point, the L1 hypervisor have no way of correctly re-injecting the #PF. Hence, if a #VMEXIT to L1 is synthesized after the #PF is injected into L2 but before it actually runs, using vcpu->arch.cr2 to update vmcb12 is also the right thing to do. Note that KVM does _not_ update vcpu->arch.cr2 when a #PF is pending for L2, only when it is injected. The distinction is important, because only injected (but not intercepted) exceptions are propagated to L1 through exit_int_info. It would be incorrect to update CR2 in vmcb12 for a pending #PF, as L1 would perceive an updated CR2 value with no #PF. Cc: stable@vger.kernel.org Signed-off-by: Yosry Ahmed <yosry.ahmed@linux.dev> Link: https://patch.msgid.link/20260203201010.1871056-1-yosry.ahmed@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-03-02x86/mtrr: Use kstrtoul() in parse_mtrr_spare_reg()Thorsten Blum1-3/+4
Replace the deprecated simple_strtoul()¹ with kstrtoul() for parsing the early boot parameter mtrr_spare_reg_nr. simple_strtoul() silently sets nr_mtrr_spare_reg to 0 for invalid input instead of rejecting it and keeping the default value. Return kstrtoul()'s retval directly to propagate parsing failures instead of treating them as success. Also return -EINVAL when '=' is missing from the boot parameter and 'arg' is NULL. ¹ https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull [ bp: Massage commit message. ] Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260302135341.3473-2-thorsten.blum@linux.dev
2026-03-02arm64: dts: imx8mp-evk: Enable pull select bit for PCIe regulator GPIO (M.2 ↵Sherry Sun1-1/+1
W_DISABLE1) The current pin configuration for MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 sets the weak pull-up but does not enable the pull select field. Bit 8 in the IOMUX register must be set in order for the weak pull-up to actually take effect. Update the pinctrl setting from 0x40 to 0x140 to enable both the pull select and the weak pull-up, ensuring the line behaves as expected. Fixes: d50650500064 ("arm64: dts: imx8mp-evk: Add PCIe support") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: imx943-evk: add usdhc3 for SDIO WiFi supportSherry Sun1-0/+61
Add usdhc3 to support M.2 SDIO WiFi on i.MX943 EVK board. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: imx952-evk: add MT35XU01G spi nor flashHaibo Chen1-0/+41
Add spi nor flash MT35XU01G support, it support OCT DTR mode at 200MHz. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: imx952: Add xspi nodeHaibo Chen1-0/+19
Add xspi node for i.MX952 Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-03-02arm64: dts: marvell: armada-37xx: drop redundant status propertyGabor Juhos1-1/+0
Remove the 'status' property from the 'armada-3700-rwtm' node. Device nodes are enabled by default, so specifying the status as "okay" is superfluous. Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-02arm64: dts: marvell: armada-37xx: align 'phy-names' of EHCI node with DT schemaGabor Juhos1-1/+1
According to the 'generic-ehci.yaml' schema, the name of the first phy in an EHCI node must be "usb", however the 'usb@5e000' node in the 'armada-37xx.dtsi' uses "usb2-utmi-host-phy" instead. This causes dtbs_check warnings like the following ones: arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dtb: usb@5e000 (marvell,armada-3700-ehci): phy-names:0: 'usb' was expected from schema $id: http://devicetree.org/schemas/usb/generic-ehci.yaml arch/arm64/boot/dts/marvell/armada-3720-db.dtb: usb@5e000 (marvell,armada-3700-ehci): phy-names:0: 'usb' was expected from schema $id: http://devicetree.org/schemas/usb/generic-ehci.yaml arch/arm64/boot/dts/marvell/armada-3720-eDPU.dtb: usb@5e000 (marvell,armada-3700-ehci): phy-names:0: 'usb' was expected from schema $id: http://devicetree.org/schemas/usb/generic-ehci.yaml ... Use "usb" as a name for the phy to avoid the warnings. No functional change, the USB interface works after the change: [ 1.472393] orion-ehci d005e000.usb: EHCI Host Controller [ 1.477847] orion-ehci d005e000.usb: new USB bus registered, assigned bus number 1 [ 1.487127] orion-ehci d005e000.usb: irq 40, io mem 0xd005e000 [ 1.505759] orion-ehci d005e000.usb: USB 2.0 started, EHCI 1.00 [ 1.512493] hub 1-0:1.0: USB hub found [ 1.516434] hub 1-0:1.0: 1 port detected ... [ 4.175746] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 4.347643] usb-storage 1-1:1.0: USB Mass Storage device detected [ 4.359972] scsi host0: usb-storage 1-1:1.0 [ 5.367100] scsi 0:0:0:0: Direct-Access ADATA USB Flash Drive 1.00 PQ: 0 ANSI: 6 [ 5.387091] sd 0:0:0:0: [sda] 30869504 512-byte logical blocks: (15.8 GB/14.7 GiB) [ 5.398420] sd 0:0:0:0: [sda] Write Protect is off [ 5.408108] sd 0:0:0:0: [sda] Write cache: disabled, read cache: disabled, doesn't support DPO or FUA [ 5.477359] sda: sda1 [ 5.480037] sd 0:0:0:0: [sda] Attached SCSI removable disk Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-02arm64: dts: marvell: armada-3720: drop 'marvell,xenon-emmc' propertiesGabor Juhos2-2/+0
The 'marvell,xenon-emmc' property used in some device trees of Armada 3720 based boards is not documented. Due to this dtbs_check throws warnings: .../armada-3720-atlas-v5.dtb: mmc@d8000 (marvell,armada-3700-sdhci): Unevaluated properties are not allowed ('marvell,xenon-emmc' was unexpected) .../armada-3720-espressobin-emmc.dtb: mmc@d8000 (marvell,armada-3700-sdhci): Unevaluated properties are not allowed ('marvell,xenon-emmc' was unexpected) Apart from the warnings, 'git grep' says that the property is used in device trees only: $ git grep -n 'marvell,xenon-emmc' arch/arm64/boot/dts/marvell/armada-3720-atlas-v5.dts:85: marvell,xenon-emmc; arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi:81: marvell,xenon-emmc; Although handling of the property was there in an early version of the 'sdhci-xenon' driver during the initial submission [1], but that part has been removed in later versions. Drop the property from the affected device trees due to the reasons mentioned above. No functional changes intended, compile tested only. Link: https://lore.kernel.org/r/0390e7a05b6163deabb545f93729ea615eeaaee2.1477911954.git-series.gregory.clement@free-electrons.com # [1] Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-02arm64: dts: marvell: uDPU: add ethernet aliasesRobert Marko1-0/+5
On eDPU plus, which is an updated revision of eDPU which uses an external MV88E6361 switch we are relying on U-Boot to detect the board, and then enable and disable the required nodes for that revision. However, it seems that I missed adding the required aliases for ethernet controllers, and this worked as in OpenWrt we had added those locally. Cc: stable@vger.kernel.org Fixes: 660b8b2f3944 ("arm64: dts: marvell: eDPU: add support for version with external switch") Signed-off-by: Robert Marko <robert.marko@sartura.hr> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-02arm/arm64: dts: marvell: Drop unused .dtsiRob Herring (Arm)3-264/+0
These .dtsi files are not included anywhere in the tree and can't be tested. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Elad Nachman <enachman@marvell.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-02arm64: dts: a7k: use phy handleElad Nachman1-1/+1
Documentation/devicetree/bindings/net/ethernet-controller.yaml phy: : #/properties/phy-handle deprecated: true New dts files should not be using deprecated properties. What should be used is: phy-handle: : /schemas/types.yaml#/definitions/phandle description: Specifies a reference to a node representing a PHY device. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Elad Nachman <enachman@marvell.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2026-03-02arm64: dts: rockchip: Make Jaguar PCIe-refclk pin use pull-up configHeiko Stuebner1-1/+1
The hardware PU/PD config of the pin after reset is to pull-up and on Jaguar this will also keep the device in reset until the driver actually enables the pin. So restore this boot pull-up config of the pin on Jaguar instead of setting it to pull-none. Suggested-by: Quentin Schulz <quentin.schulz@cherry.de> Fixes: 0ec7e1096332 ("arm64: dts: rockchip: add PCIe3 support on rk3588-jaguar") Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://patch.msgid.link/20260210080303.680403-5-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02arm64: dts: rockchip: add pinctrl for clk-generator GPIO on rk3588-tigerHeiko Stuebner1-0/+8
While specific driver in the Linux-Kernel handles GPIOs gracefully without matching pinctrl entries, this might not be true for other operating systems. So having pinctrl entries makes the hardware-description more complete. The somewhat similar rk3588-jaguar board has a pinctrl entry already, so also add one for rk3588-tiger. Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Link: https://patch.msgid.link/20260210080303.680403-4-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-tigerHeiko Stuebner1-14/+5
Using a combination of fixed clock and gpio-gate clock works but does not describe the actual hardware. Use the gated-fixed-clock binding to describe this in a nicer way. Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://patch.msgid.link/20260210080303.680403-3-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02arm64: dts: rockchip: use gated-fixed-clock for pcie-refclk on rk3588-jaguarHeiko Stuebner1-14/+5
Using a combination of fixed clock and gpio-gate clock works but does not describe the actual hardware. Use the gated-fixed-clock binding to describe this in a nicer way. Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://patch.msgid.link/20260210080303.680403-2-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02arm64: dts: rockchip: Enable displayport for rk3576 evb2Chaoyi Chen1-0/+49
The rk3576 evb2 has a full size displayport connector. Enable it. Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Link: https://patch.msgid.link/20260224083818.109-1-kernel@airkyi.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02arm64: dts: rockchip: Add battery and charger on rk3566-pinenoteSamuel Holland1-0/+26
The PineNote has a single cell 4000mAh battery which can be charged via the rk817 PMIC. Signed-off-by: Samuel Holland <samuel@sholland.org> Co-developed-by: Maximilian Weigand <mweigand@mweigand.net> Signed-off-by: Maximilian Weigand <mweigand@mweigand.net> Signed-off-by: Diederik de Haas <diederik@cknow-tech.com> Link: https://patch.msgid.link/20260224170531.516392-1-diederik@cknow-tech.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02riscv: dts: spacemit: adapt regulator node name to preferred formYixun Lan2-7/+7
The preferred node name for fixed-regulators has changed to pattern [1]: '^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$' Adjust all SpacemiT DT regulator node names to fix this. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20240426215147.3138211-1-robh@kernel.org [1] Link: https://lore.kernel.org/r/20260226-02-k1-regulator-names-v1-1-e87695d50159@kernel.org Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-03-02arm64: dts: rockchip: Fix sdmmc pwren pinctrl for rk3576-evb2Chaoyi Chen1-0/+2
In rk3576.dtsi, sdmmc0_pwren is configured as part of the sdmmc pinctrl. However, on the rk3576 evb2 board, sdmmc0_pwren is used as the regulator for vmmc-supply. Therefore, we need to reassign the sdmmc pinctrl and remove sdmmc0_pwren to avoid conflicts. Cc: Shawn Lin <shawn.lin@rock-chips.com> Fixes: 86a82f7a7eed ("arm64: dts: rockchip: Add rk3576 evb2 board") Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Link: https://patch.msgid.link/20260226102052.63-1-kernel@airkyi.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-03-02arm64: dts: zena: Add support for Zena CSSDebbie Horsfall3-0/+833
Introduce the Zena CSS Fixed Virtual Platform (FVP) dts. This is currently the only Zena CSS variant, however the common definitions are included in a common dtsi for extensibility. Signed-off-by: Debbie Horsfall <debbie.horsfall@arm.com> Message-Id: <20260212-zena-css-v2-2-d33ea23cb9c2@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-21 14:01:27 +0300