summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-11-24irqchip/gic: Expose CPU interface VA to KVMMarc Zyngier
Future changes will require KVM to be able to perform deactivations by writing to the physical CPU interface. Add the corresponding VA to the kvm_info structure, and let KVM stash it. Tested-by: Fuad Tabba <tabba@google.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Mark Brown <broonie@kernel.org> Link: https://msgid.link/20251120172540.2267180-3-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2025-11-24KVM: arm64: nv: Forward FEAT_XNX permissions to the shadow stage-2Oliver Upton
Add support for FEAT_XNX to shadow stage-2 MMUs, being careful to only evaluate XN[0] when the feature is actually exposed to the VM. Restructure the layering of permissions in the fault handler to assume pX and uX then restricting based on the guest's stage-2 afterwards. Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Link: https://msgid.link/20251124190158.177318-4-oupton@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2025-11-24KVM: arm64: Add support for FEAT_XNX stage-2 permissionsOliver Upton
FEAT_XNX adds support for encoding separate execute permissions for EL0 and EL1 at stage-2. Add support for this to the page table library, hiding the unintuitive encoding scheme behind generic pX and uX permission flags. Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Link: https://msgid.link/20251124190158.177318-3-oupton@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2025-11-24arm64: Detect FEAT_XNXOliver Upton
Detect the feature in anticipation of using it in KVM. Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Link: https://msgid.link/20251124190158.177318-2-oupton@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2025-11-24cpumask: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24x86_64/bug: Inline the UD1Peter Zijlstra
(Ab)use the static_call infrastructure to convert all: call __WARN_trap instances into the desired: ud1 (%edx), %rdi eliminating the CALL/RET, but more importantly, fixing the fact that all WARNs will have: RIP: 0010:__WARN_trap+0 Basically, by making it a static_call trampoline call, objtool will collect the callsites, and then the inline rewrite will hit the special case and replace the code with the magic instruction. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.456717741@infradead.org
2025-11-24x86/bug: Implement WARN_ONCE()Peter Zijlstra
Implement WARN_ONCE like WARN using BUGFLAG_ONCE. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.339309119@infradead.org
2025-11-24x86_64/bug: Implement __WARN_printf()Peter Zijlstra
The basic idea is to have __WARN_printf() be a vararg function such that the compiler can do the optimal calling convention for us. This function body will be a #UD and then set up a va_list in the exception from pt_regs. But because the trap will be in a called function, the bug_entry must be passed in. Have that be the first argument, with the format tucked away inside the bug_entry. The comments should clarify the real fun details. The big downside is that all WARNs will now show: RIP: 0010:__WARN_trap:+0 One possible solution is to simply discard the top frame when unwinding. A follow up patch takes care of this slightly differently by abusing the x86 static_call implementation. This changes (with the next patches): WARN_ONCE(preempt_count() != 2*PREEMPT_DISABLE_OFFSET, "corrupted preempt_count: %s/%d/0x%x\n", from: cmpl $2, %ecx #, _7 jne .L1472 ... .L1472: cmpb $0, __already_done.11(%rip) je .L1513 ... .L1513 movb $1, __already_done.11(%rip) movl 1424(%r14), %edx # _15->pid, _15->pid leaq 1912(%r14), %rsi #, _17 movq $.LC43, %rdi #, call __warn_printk # ud2 .pushsection __bug_table,"aw" 2: .long 1b - . # bug_entry::bug_addr .long .LC1 - . # bug_entry::file .word 5093 # bug_entry::line .word 2313 # bug_entry::flags .org 2b + 12 .popsection .pushsection .discard.annotate_insn,"M", @progbits, 8 .long 1b - . .long 8 # ANNOTYPE_REACHABLE .popsection into: cmpl $2, %ecx #, _7 jne .L1442 #, ... .L1442: lea (2f)(%rip), %rdi 1: .pushsection __bug_table,"aw" 2: .long 1b - . # bug_entry::bug_addr .long .LC43 - . # bug_entry::format .long .LC1 - . # bug_entry::file .word 5093 # bug_entry::line .word 2323 # bug_entry::flags .org 2b + 16 .popsection movl 1424(%r14), %edx # _19->pid, _19->pid leaq 1912(%r14), %rsi #, _13 ud1 (%edx), %rdi Notably, by pushing everything into the exception handler it can take care of the ONCE thing. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.213813530@infradead.org
2025-11-24x86/bug: Use BUG_FORMAT for DEBUG_BUGVERBOSE_DETAILEDPeter Zijlstra
Since we have an explicit format string, use it for the condition string instead of frobbing it in the file string. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115758.097401406@infradead.org
2025-11-24x86/bug: Add BUG_FORMAT basicsPeter Zijlstra
Opt-in to BUG_FORMAT for x86_64, adjust the BUGTABLE helper and for now, just store NULL pointers. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251110115757.980264454@infradead.org
2025-11-24bpf: specify the old and new poke_type for bpf_arch_text_pokeMenglong Dong
In the origin logic, the bpf_arch_text_poke() assume that the old and new instructions have the same opcode. However, they can have different opcode if we want to replace a "call" insn with a "jmp" insn. Therefore, add the new function parameter "old_t" along with the "new_t", which are used to indicate the old and new poke type. Meanwhile, adjust the implement of bpf_arch_text_poke() for all the archs. "BPF_MOD_NOP" is added to make the code more readable. In bpf_arch_text_poke(), we still check if the new and old address is NULL to determine if nop insn should be used, which I think is more safe. Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Link: https://lore.kernel.org/r/20251118123639.688444-6-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-11-24bpf,x86: adjust the "jmp" mode for bpf trampolineMenglong Dong
In the origin call case, if BPF_TRAMP_F_SKIP_FRAME is not set, it means that the trampoline is not called, but "jmp". Introduce the function bpf_trampoline_use_jmp() to check if the trampoline is in "jmp" mode. Do some adjustment on the "jmp" mode for the x86_64. The main adjustment that we make is for the stack parameter passing case, as the stack alignment logic changes in the "jmp" mode without the "rip". What's more, the location of the parameters on the stack also changes. Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Link: https://lore.kernel.org/r/20251118123639.688444-5-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-11-24bpf: fix the usage of BPF_TRAMP_F_SKIP_FRAMEMenglong Dong
Some places calculate the origin_call by checking if BPF_TRAMP_F_SKIP_FRAME is set. However, it should use BPF_TRAMP_F_ORIG_STACK for this propose. Just fix them. Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Acked-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/r/20251118123639.688444-4-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-11-24x86/ftrace: Implement DYNAMIC_FTRACE_WITH_JMPMenglong Dong
Implement the DYNAMIC_FTRACE_WITH_JMP for x86_64. In ftrace_call_replace, we will use JMP32_INSN_OPCODE instead of CALL_INSN_OPCODE if the address should use "jmp". Meanwhile, adjust the direct call in the ftrace_regs_caller. The RSB is balanced in the "jmp" mode. Take the function "foo" for example: original_caller: call foo -> foo: call fentry -> fentry: [do ftrace callbacks ] move tramp_addr to stack RET -> tramp_addr tramp_addr: [..] call foo_body -> foo_body: [..] RET -> back to tramp_addr [..] RET -> back to original_caller Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20251118123639.688444-3-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-11-24Merge tag 'icc-6.19-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: interconnect changes for 6.19 This pull request contains the interconnect changes for the 6.19-rc1 merge window. The core and driver changes are listed below. Core changes: - kbps_to_icc() macro optimization Driver changes: - Switch all Qualcomm RPMh interconnect drivers to use the dynamic node IDs and drop support for non-dynamic ID allocation - Add new driver and BWMON support for the Kaanapali SoC - Add QoS support for the SM6350 SoC - Add QoS support for the SA8775p SoC - Fix missing link from SNOC_PNOC to the USB 2 on MSM8996 SoC that includes also a dts change that has been acked by the maintainer - Drop the QPIC interconnect and BCM nodes for the SDX75 SoC, as these should be handled by the rpmh-clk driver - Other misc fixes Signed-off-by: Georgi Djakov <djakov@kernel.org> * tag 'icc-6.19-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc: (40 commits) interconnect: qcom: sm6350: enable QoS configuration interconnect: qcom: sm6350: Remove empty BCM arrays interconnect: qcom: icc-rpmh: Get parent's regmap for nested NoCs dt-bindings: interconnect: qcom,sm6350-rpmh: Add clocks for QoS dt-bindings: interconnect: qcom-bwmon: Document Kaanapali BWMONs interconnect: qcom: icc-rpmh: drop support for non-dynamic IDS interconnect: qcom: sm8750: convert to dynamic IDs interconnect: qcom: sm8650: convert to dynamic IDs interconnect: qcom: sm8550: convert to dynamic IDs interconnect: qcom: sm8450: convert to dynamic IDs interconnect: qcom: sm8350: convert to dynamic IDs interconnect: qcom: sm8150: convert to dynamic IDs interconnect: qcom: sm7150: convert to dynamic IDs interconnect: qcom: sm6350: convert to dynamic IDs interconnect: qcom: sdx75: convert to dynamic IDs interconnect: qcom: sdx65: convert to dynamic IDs interconnect: qcom: sdx55: convert to dynamic IDs interconnect: qcom: sdm670: convert to dynamic IDs interconnect: qcom: sc7180: convert to dynamic IDs interconnect: qcom: sar2130p: convert to dynamic IDs ...
2025-11-24arm64: proton-pack: Fix hard lockup when !MITIGATE_SPECTRE_BRANCH_HISTORYJonathan Marek
The "drop print" commit removed the whole branch and not just the print. For some ARM64 cpus, this leads to hard lockup when CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY is not enabled. Fixes: 62e72463ca71 ("arm64: proton-pack: Drop print when !CONFIG_MITIGATE_SPECTRE_BRANCH_HISTORY") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-24Revert "arm64: acpi: Enable ACPI CCEL support"Will Deacon
This reverts commit d02c2e45b1e7767b177f6854026e4ad0d70b4a4d. Mauro reports that this breaks APEI notifications on his QEMU setup because the "reserved for firmware" region still needs to be writable by Linux in order to signal _back_ to the firmware after processing the reported error: | {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 1 | ... | [Firmware Warn]: GHES: Unhandled processor error type 0x02: cache error | Unable to handle kernel write to read-only memory at virtual address ffff800080035018 | Mem abort info: | ESR = 0x000000009600004f | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x0f: level 3 permission fault | Data abort info: | ISV = 0, ISS = 0x0000004f, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | swapper pgtable: 4k pages, 52-bit VAs, pgdp=00000000505d7000 | pgd=10000000510bc003, p4d=1000000100229403, pud=100000010022a403, pmd=100000010022b403, pte=0060000139b90483 | Internal error: Oops: 000000009600004f [#1] SMP For now, revert the offending commit. We can presumably switch back to PAGE_KERNEL when bringing this back in the future. Link: https://lore.kernel.org/r/20251121224611.07efa95a@foz.lan Reported-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-24um: drivers: virtio: use string choices helperKuninori Morimoto
Remove hard-coded strings by using the string helper functions Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87h5uywtwp.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-11-24s390: Add stackprotector supportHeiko Carstens
Stackprotector support was previously unavailable on s390 because by default compilers generate code which is not suitable for the kernel: the canary value is accessed via thread local storage, where the address of thread local storage is within access registers 0 and 1. Using those registers also for the kernel would come with a significant performance impact and more complicated kernel entry/exit code, since access registers contents would have to be exchanged on every kernel entry and exit. With the upcoming gcc 16 release new compiler options will become available which allow to generate code suitable for the kernel. [1] Compiler option -mstack-protector-guard=global instructs gcc to generate stackprotector code that refers to a global stackprotector canary value via symbol __stack_chk_guard. Access to this value is guaranteed to occur via larl and lgrl instructions. Furthermore, compiler option -mstack-protector-guard-record generates a section containing all code addresses that reference the canary value. To allow for per task canary values the instructions which load the address of __stack_chk_guard are patched so they access a lowcore field instead: a per task canary value is available within the task_struct of each task, and is written to the per-cpu lowcore location on each context switch. Also add sanity checks and debugging option to be consistent with other kernel code patching mechanisms. Full debugging output can be enabled with the following kernel command line options: debug_stackprotector bootdebug ignore_loglevel earlyprintk dyndbg="file stackprotector.c +p" Example debug output: stackprot: 0000021e402d4eda: c010005a9ae3 -> c01f00070240 where "<insn address>: <old insn> -> <new insn>". [1] gcc commit 0cd1f03939d5 ("s390: Support global stack protector") Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-24s390/modules: Simplify module_finalize() slightlyHeiko Carstens
Preinitialize the return value, and break out the for loop in module_finalize() in case of an error to get rid of an ifdef. This makes it easier to add additional code, which may also depend on config options. Reviewed-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-24s390: Remove KMSG_COMPONENT macroHeiko Carstens
The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter <tmricht@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-24s390/percpu: Get rid of ARCH_MODULE_NEEDS_WEAK_PER_CPUHeiko Carstens
Since the rework of the kernel virtual address space [1] the module area and the kernel image are within the same 4GB area. Therefore there is no need for the weak per cpu workaround for modules anymore. Remove it. [1] commit c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces") Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-11-24m68k: defconfig: Update defconfigs for v6.18-rc1Geert Uytterhoeven
- Drop CONFIG_SCTP_COOKIE_HMAC_SHA1=y (removed in commit 2f3dd6ec901f29ae ("sctp: Convert cookie authentication to use HMAC-SHA256")), - Drop CONFIG_BATMAN_ADV_NC=y (removed in commit 87b95082db32ae1c ("batman-adv: remove network coding support")), - Enable modular build of the SHA-1 secure hash algorithm (no longer auto-enabled since commit 2f3dd6ec901f29ae ("sctp: Convert cookie authentication to use HMAC-SHA256")). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patch.msgid.link/65e00bcb7b2980278bb087986ee405627aa32d8b.1760360254.git.geert@linux-m68k.org
2025-11-24crypto: aesni - ctr_crypt() use min() instead of min_t()David Laight
min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'. Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long' and so cannot discard significant bits. In this case the 'unsigned long' value is small enough that the result is ok. Detected by an extra check added to min_t(). Signed-off-by: David Laight <david.laight.linux@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-11-24RISC-V: KVM: Flush VS-stage TLB after VCPU migration for Andes coresHui Min Mina Chou
Most implementations cache the combined result of two-stage translation, but some, like Andes cores, use split TLBs that store VS-stage and G-stage entries separately. On such systems, when a VCPU migrates to another CPU, an additional HFENCE.VVMA is required to avoid using stale VS-stage entries, which could otherwise cause guest faults. Introduce a static key to identify CPUs with split two-stage TLBs. When enabled, KVM issues an extra HFENCE.VVMA on VCPU migration to prevent stale VS-stage mappings. Signed-off-by: Hui Min Mina Chou <minachou@andestech.com> Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Reviewed-by: Radim Krčmář <rkrcmar@ventanamicro.com> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Link: https://lore.kernel.org/r/20251117084555.157642-1-minachou@andestech.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-24RISC-V: KVM: Fix guest page fault within HLV* instructionsFangyu Yu
When executing HLV* instructions at the HS mode, a guest page fault may occur when a g-stage page table migration between triggering the virtual instruction exception and executing the HLV* instruction. This may be a corner case, and one simpler way to handle this is to re-execute the instruction where the virtual instruction exception occurred, and the guest page fault will be automatically handled. Fixes: b91f0e4cb8a3 ("RISC-V: KVM: Factor-out instruction emulation into separate sources") Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20251121133543.46822-1-fangyu.yu@linux.alibaba.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-24KVM: riscv: Support enabling dirty log gradually in small chunksDong Yang
There is already support of enabling dirty log gradually in small chunks for x86 in commit 3c9bd4006bfc ("KVM: x86: enable dirty log gradually in small chunks") and c862626 ("KVM: arm64: Support enabling dirty log gradually in small chunks"). This adds support for riscv. x86 and arm64 writes protect both huge pages and normal pages now, so riscv protect also protects both huge pages and normal pages. On a nested virtualization setup (RISC-V KVM running inside a QEMU VM on an [Intel® Core™ i5-12500H] host), I did some tests with a 2G Linux VM using different backing page sizes. The time taken for memory_global_dirty_log_start in the L2 QEMU is listed below: Page Size Before After Optimization 4K 4490.23ms 31.94ms 2M 48.97ms 45.46ms 1G 28.40ms 30.93ms Signed-off-by: Quan Zhou <zhouquan@iscas.ac.cn> Signed-off-by: Dong Yang <dayss1224@gmail.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20251103062825.9084-1-dayss1224@gmail.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-24RISC-V: KVM: Introduce KVM_EXIT_FAIL_ENTRY_NO_VSFILEBillXiang
Currently, we return CSR_HSTATUS as hardware_entry_failure_reason when kvm_riscv_aia_alloc_hgei failed in KVM_DEV_RISCV_AIA_MODE_HWACCEL mode, which is vague so it is better to return a well defined value KVM_EXIT_FAIL_ENTRY_NO_VSFILE provided via uapi/asm/kvm.h. Signed-off-by: BillXiang <xiangwencheng@lanxincomputing.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20250923053851.32863-1-xiangwencheng@lanxincomputing.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-24RISC-V: KVM: Add SBI MPXY extension support for GuestAnup Patel
The SBI MPXY extension is a platform-level functionality so KVM only needs to forward SBI MPXY calls to KVM user-space. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20251017155925.361560-4-apatel@ventanamicro.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-24RISC-V: KVM: Add separate source for forwarded SBI extensionsAnup Patel
Add a separate source vcpu_sbi_forward.c for SBI extensions which are entirely forwarded to KVM user-space. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20251017155925.361560-3-apatel@ventanamicro.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-24RISC-V: KVM: Convert kvm_riscv_vcpu_sbi_forward() into extension handlerAnup Patel
All uses of kvm_riscv_vcpu_sbi_forward() also updates retdata->uexit so to further reduce code duplication move retdata->uexit assignment to kvm_riscv_vcpu_sbi_forward() and convert it into SBI extension handler. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20251017155925.361560-2-apatel@ventanamicro.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-11-23riscv: dts: sifive: unmatched: Add PWM controlled fansRené Rebe
This adds the two PWM-controlled fans of the HiFive Unmatched board to the device tree. Signed-off-by: René Rebe <rene@exactco.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-11-23Merge tag 'perf-urgent-2025-11-23' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "Fix perf CPU-clock counters, and address a static checker warning" * tag 'perf-urgent-2025-11-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix 0 count issue of cpu-clock perf/x86/intel/uncore: Remove superfluous check
2025-11-22Merge tag 'mips-fixes_6.18_1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux Pull MIPS fixes from Thomas Bogendoerfer: - Fix CPU type in DT for econet - Fix for Malta PCI MMIO breakage for SOC-it - Fix TLB shutdown caused by iniital uniquification - Fix random seg faults due to missed vdso storage requirement * tag 'mips-fixes_6.18_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: kernel: Fix random segmentation faults MIPS: mm: Prevent a TLB shutdown on initial uniquification mips: dts: econet: fix EN751221 core type MIPS: Malta: Fix !EVA SOC-it PCI MMIO
2025-11-22x86/{boot,mtrr}: Remove unused function declarationsYue Haibing
Commits 28be1b454c2b ("x86/boot: Remove unused copy_*_gs() functions") 34d2819f2078 ("x86, mtrr: Remove unused mtrr/state.c") removed the functions but left the prototypes. Remove them. [ bp: Merge into a single patch. ] Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251120121037.1479334-1-yuehaibing@huawei.com
2025-11-22Merge tag 'riscv-for-linus-6.18-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Paul Walmsley: - Correct the MIPS RISC-V/JEDEC vendor ID - Fix the system shutdown behavior in the legacy case where CONFIG_RISCV_SBI_V01 is set, but the firmware implementation doesn't support the older v0.1 system shutdown method - Align some tools/ macro definitions with the corresponding kernel headers * tag 'riscv-for-linus-6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: tools: riscv: Fixed misalignment of CSR related definitions riscv: sbi: Prefer SRST shutdown over legacy riscv: Update MIPS vendor id to 0x127
2025-11-22crypto: ansi_cprng - Remove unused ansi_cprng algorithmEric Biggers
Remove ansi_cprng, since it's obsolete and unused, as confirmed at https://lore.kernel.org/r/aQxpnckYMgAAOLpZ@gondor.apana.org.au/ This was originally added in 2008, apparently as a FIPS approved random number generator. Whether this has ever belonged upstream is questionable. Either way, ansi_cprng is no longer usable for this purpose, since it's been superseded by the more modern algorithms in crypto/drbg.c, and FIPS itself no longer allows it. (NIST SP 800-131A Rev 1 (2015) says that RNGs based on ANSI X9.31 will be disallowed after 2015. NIST SP 800-131A Rev 2 (2019) confirms they are now disallowed.) Therefore, there is no reason to keep it around. Suggested-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Haotian Zhang <vulab@iscas.ac.cn> Cc: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-11-22riscv: dts: allwinner: d1: fix vlenb propertySergey Matyukevich
According to [1], the C906 vector registers are 128 bits wide. The 'thead,vlenb' property specifies the vector register length in bytes, so its value must be set to 16. [1] https://dl.linux-sunxi.org/D1/Xuantie_C906_R1S0_User_Manual.pdf Fixes: ce1daeeba600 ("riscv: dts: allwinner: Add xtheadvector to the D1/D1s devicetree") Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com> Link: https://patch.msgid.link/20251119203508.1032716-1-geomatsi@gmail.com Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-11-21bpf: arm64: Add support for indirect jumpsPuranjay Mohan
Add support for a new instruction BPF_JMP|BPF_X|BPF_JA, SRC=0, DST=Rx, off=0, imm=0 which does an indirect jump to a location stored in Rx. The register Rx should have type PTR_TO_INSN. This new type assures that the Rx register contains a value (or a range of values) loaded from a correct jump table – map of type instruction array. ARM64 JIT supports indirect jumps to all registers through the A64_BR() macro, use it to implement this new instruction. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Anton Protopopov <a.s.protopopov@gmail.com> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20251117130732.11107-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-11-21bpf: arm64: Add support for instructions arrayPuranjay Mohan
Add support for the instructions array map type in the arm64 JIT by calling bpf_prog_update_insn_ptrs() with the offsets that map xlated_offset to the jited_offset in the final image. arm64 JIT already has this offset array which was being used for bpf_prog_fill_jited_linfo() and can be used directly for bpf_prog_update_insn_ptrs. Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Reviewed-by: Anton Protopopov <a.s.protopopov@gmail.com> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20251117130732.11107-2-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-11-21arm64: dts: rockchip: enable RTC for 100ASK DshanPi A1Chukun Pan
Enable RTC support for the 100ASK DshanPi A1 board. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://patch.msgid.link/20251120120011.279104-6-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-11-21arm64: dts: rockchip: enable USB for 100ASK DshanPi A1Chukun Pan
Enable USB support for the 100ASK DshanPi A1 board. Note that the HUSB311 Type-C chip is not supported. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://patch.msgid.link/20251120120011.279104-5-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-11-21arm64: dts: rockchip: enable button for 100ASK DshanPi A1Chukun Pan
The 100ASK DshanPi A1 board has three ADC buttons and one GPIO button. Enable them. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://patch.msgid.link/20251120120011.279104-4-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-11-21arm64: dts: rockchip: add mmc aliases for 100ASK DshanPi A1Chukun Pan
Add missing MMC aliases for 100ASK DshanPi A1 board. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Link: https://patch.msgid.link/20251120120011.279104-3-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-11-21arm64: dts: rockchip: remove mmc max-frequency for 100ASK DshanPi A1Chukun Pan
The max-frequency property is already defined in the mmc node of rk3576.dtsi. Remove the redundant definition. Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/20251120120011.279104-2-amadeus@jmu.edu.cn Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-11-21arm64: dts: rockchip: Enable i2c2 on Orange Pi 3BMichael Opdenacker
Enable the "i2c2" bus on header pins 3 (I2C_SDA_M1) and 5 (I2C2_SCL_M1) of the Orange Pi 3B board. As documented on http://www.orangepi.org/img/pi3b/0719-pi3b-19.png, such pins are the only ones offering I2C functionality without conflicting with other SoC blocks. Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> Link: https://patch.msgid.link/20251120-orangepi3-enable-i2c2-v1-1-2e023a74012a@rootcommit.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-11-21x86,fs/resctrl: Implement "io_alloc" enable/disable handlersBabu Moger
"io_alloc" is the generic name of the new resctrl feature that enables system software to configure the portion of cache allocated for I/O traffic. On AMD systems, "io_alloc" resctrl feature is backed by AMD's L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE). Introduce the architecture-specific functions that resctrl fs should call to enable, disable, or check status of the "io_alloc" feature. Change SDCIAE state by setting (to enable) or clearing (to disable) bit 1 of MSR_IA32_L3_QOS_EXT_CFG on all logical processors within the cache domain. Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://patch.msgid.link/9e9070100c320eab5368e088a3642443dee95ed7.1762995456.git.babu.moger@amd.com
2025-11-21Merge tag 'omap-for-v6.19/soc-signed' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap into soc/arm ARM: OMAP2+: Fix falg->flag typo in omap_smc2() * tag 'omap-for-v6.19/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap: ARM: OMAP2+: Fix falg->flag typo in omap_smc2() Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-11-21ARM: gemini: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20251023204737.2716443-1-linus.walleij@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-11-21x86,fs/resctrl: Detect io_alloc featureBabu Moger
AMD's SDCIAE (SDCI Allocation Enforcement) PQE feature enables system software to control the portions of L3 cache used for direct insertion of data from I/O devices into the L3 cache. Introduce a generic resctrl cache resource property "io_alloc_capable" as the first part of the new "io_alloc" resctrl feature that will support AMD's SDCIAE. Any architecture can set a cache resource as "io_alloc_capable" if a portion of the cache can be allocated for I/O traffic. Set the "io_alloc_capable" property for the L3 cache resource on x86 (AMD) systems that support SDCIAE. Signed-off-by: Babu Moger <babu.moger@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://patch.msgid.link/df85a9a6081674fd3ef6b4170920485512ce2ded.1762995456.git.babu.moger@amd.com
generated by cgit v1.2.3 (git 2.51.0) at 2026-10-19 00:15:42 +0000