summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-09-18arm64: dts: apple: Add J474s, J475c and J475d device treesJanne Grunau
Add device trees for the M2 Pro Mac mini and the M2 Max and Ultra Mac Studio. These devices are very similar to the M1 Max and Ultra Mac Studio so reuse the device template, include the .dtsi for the new SoCs and correct for the minimal differences. Co-developed-by: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sven Peter <sven@kernel.org>
2025-09-18arm64: dts: apple: Add J414 and J416 Macbook Pro device treesHector Martin
Add device trees for the T6020 and T6021 based Macbook Pros (M2 Pro/Max, 14/16-inch). The devices are very similar to the T6000/T6001 based ones so reuse the device templates, include the new SoCs and correct for the minimal differences. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Co-developed-by: Janne Grunau <j@jannau.net> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sven Peter <sven@kernel.org>
2025-09-18arm64: dts: apple: Add initial t6020/t6021/t6022 DTsHector Martin
These SoCs are found in Apple devices with M2 Pro (t6020), M2 Max (t6021) and M2 Ultra (t6022) and follow the pattern of their M1 counterparts. t6020 is a cut-down version of t6021, so the former just includes the latter and disables the missing bits (This is currently just one PMGR node and all of its domains). t6022 is two connected t6021 dies. The implementation seems to use t6021 with blocks disabled (mostly on the second die). MMIO addresses on the second die have a constant offset. The interrupt controller is multi-die aware. This setup can be represented in the device tree with two top level "soc" nodes. The MMIO offset is applied via "ranges" and devices are included with preproceesor macros to make the node labels unique and to specify the die number for the interrupt definition. Device nodes are distributed over dtsi files based on whether they are present on both dies or just on the first die. The only exception is the NVMe controller which resides on the second die. Its nodes are in a separate file. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Neal Gompa <neal@gompa.dev> Co-developed-by: Janne Grunau <j@jannau.net> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sven Peter <sven@kernel.org>
2025-09-18arm64: dts: apple: Add ethernet0 alias for J375 templateJanne Grunau
The alias is used by the boot loader to fill the MAC address. Fixes: aaa1d42a4ce3 ("arm64: dts: apple: Add J375 devicetrees") Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Janne Grunau <j@jannau.net> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Sven Peter <sven@kernel.org>
2025-09-17arm64: dts: qcom: Add base HAMOA-IOT-EVK boardYijie Yang
The HAMOA-IOT-EVK is an evaluation platform for IoT products, composed of the Hamoa IoT SoM and a carrier board. Together, they form a complete embedded system capable of booting to UART. Make the following peripherals on the carrier board enabled: - UART - On-board regulators - USB Type-C mux - Pinctrl - Embedded USB (EUSB) repeaters - NVMe - pmic-glink - USB DisplayPorts - Bluetooth - WLAN - Audio Written in collaboration with Quill Qi (Audio) <le.qi@oss.qualcomm.com>, Jie Zhang (Graphics) <quic_jiezh@quicinc.com>, Shuai Zhang (Bluetooth) <quic_shuaz@quicinc.com>, Yingying Tang (WLAN) <quic_yintang@quicinc.com>, and Yongxing Mou (USB DisplayPorts) <quic_yongmou@quicinc.com>. Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250917-hamoa_initial-v12-3-4ed39d17dfc5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17arm64: dts: qcom: Add HAMOA-IOT-SOM platformYijie Yang
The HAMOA-IOT-SOM is a compact computing module that integrates a System on Chip (SoC) — specifically the x1e80100 — along with essential components optimized for IoT applications. It is designed to be mounted on carrier boards, enabling the development of complete embedded systems. Make the following peripherals on the SOM enabled: - Regulators on the SOM - Reserved memory regions - PCIe6a and its PHY - PCIe4 and its PHY - USB0 through USB6 and their PHYs - ADSP, CDSP - Graphic - Video Written in collaboration with Yingying Tang (PCIe4) <quic_yintang@quicinc.com> and Wangao Wang (Video) <quic_wangaow@quicinc.com>. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250917-hamoa_initial-v12-2-4ed39d17dfc5@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17riscv: mm: Return intended SATP mode for noXlvl optionsJunhui Liu
Change the return value of match_noXlvl() to return the SATP mode that will be used, rather than the mode being disabled. This enables unified logic for return value judgement with the function that obtains mmu-type from the fdt, avoiding extra conversion. This only changes the naming, with no functional impact. Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://lore.kernel.org/r/20250722-satp-from-fdt-v1-1-5ba22218fa5f@pigmoral.tech Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-17arm64: dts: qcom: sm8750-mtp: Add WiFi and BluetoothKrzysztof Kozlowski
MTP8750 rev 2.0 (power grid v8) boards come as two different variants with different WiFi chips: WCN7850 and WCN786x. WCN7850 is already supported by the kernel, but WCN786x is not. Both of the board variants are considered newest revisions and the difference is only in MCN numbers and internal codenames. Add WCN7850 WiFi and Bluetooth to the MTP8750, stating that this DTS represents the WCN7850 variant. The S4D and S5F regulators should operate at 0.85 V, thus adjust lower constraint and regulator name. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250902140018.247209-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17arm64: dts: qcom: msm8953-xiaomi-daisy: fix cd-gpiosBarnabás Czémán
SD detection was not working because cd-gpios flag was wrongly configured, according to downstream sources device is using GPIO_ACTIVE_HIGH. Fix SD detection with change cd-gpios from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH. Fixes: 38d779c26395 ("arm64: dts: qcom: msm8953: Add device tree for Xiaomi Mi A2 Lite") Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250903-daisy-sd-fix-v2-1-e08c50f3be57@mainlining.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17bpf, arm64: Call bpf_jit_binary_pack_finalize() in bpf_jit_free()Hengqi Chen
The current implementation seems incorrect and does NOT match the comment above, use bpf_jit_binary_pack_finalize() instead. Fixes: 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management") Acked-by: Puranjay Mohan <puranjay@kernel.org> Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Acked-by: Song Liu <song@kernel.org> Acked-by: Puranjay Mohan <puranjay@kernel.org> Link: https://lore.kernel.org/r/20250916232653.101004-1-hengqi.chen@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-09-17Merge tag 'kvm-s390-master-6.17-1' of ↵Paolo Bonzini
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD - KVM mm fixes - Postcopy fix
2025-09-17Merge tag 'kvm-x86-fixes-6.17-rcN' of https://github.com/kvm-x86/linux into HEADPaolo Bonzini
KVM x86 fix for 6.17-rcN Sync the vTPR from the local APIC to the VMCB even when AVIC is active, to fix a bug where host updates to the vTPR, e.g. via KVM_SET_LAPIC or emulation of a guest access, effectively get lost and result in interrupt delivery issues in the guest.
2025-09-17Merge tag 'kvmarm-fixes-6.17-2' of ↵Paolo Bonzini
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 6.17, round #3 - Invalidate nested MMUs upon freeing the PGD to avoid WARNs when visiting from an MMU notifier - Fixes to the TLB match process and TLB invalidation range for managing the VCNR pseudo-TLB - Prevent SPE from erroneously profiling guests due to UNKNOWN reset values in PMSCR_EL1 - Fix save/restore of host MDCR_EL2 to account for eagerly programming at vcpu_load() on VHE systems - Correct lock ordering when dealing with VGIC LPIs, avoiding scenarios where an xarray's spinlock was nested with a *raw* spinlock - Permit stage-2 read permission aborts which are possible in the case of NV depending on the guest hypervisor's stage-2 translation - Call raw_spin_unlock() instead of the internal spinlock API - Fix parameter ordering when assigning VBAR_EL1
2025-09-17KVM: arm64: Use ARM64_HAS_GICV5_LEGACY for GICv5 probingSascha Bischoff
The previous implementation of the probing function had the flaw that it wouldn't catch mismatched CPU features. Specifically, GICv5 legacy support (support for GICv3 VMs on a GICv5 host) was being enabled as long as the initial boot CPU had support for the feature. This allowed the support to become enabled on mismatched configurations. Move to using cpus_have_final_cap(ARM64_HAS_GICV5_LEGACY) instead, which only returns true when all booted CPUs support FEAT_GCIE_LEGACY. A byproduct of this is that it ensures that late onlining of CPUs is blocked on feature mismatch. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17arm64: cpucaps: Add GICv5 Legacy vCPU interface (GCIE_LEGACY) capabilitySascha Bischoff
Implement the GCIE_LEGACY capability as a system feature to be able to check for support from KVM. The type is explicitly ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE, which means that the capability is enabled early if all boot CPUs support it. Additionally, if this capability is enabled during boot, it prevents late onlining of CPUs that lack it, thereby avoiding potential mismatched configurations which would break KVM. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Enable nested for GICv5 host with FEAT_GCIE_LEGACYSascha Bischoff
Extend the NV check to pass for a GICv5 host that has FEAT_GCIE_LEGACY. The has_gcie_v3_compat flag is only set on GICv5 hosts (that explicitly support FEAT_GCIE_LEGACY), and hence the explicit check for a VGIC_V5 is omitted. As of this change, vGICv3-based VMs can run with nested on a compatible GICv5 host. Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Don't access ICC_SRE_EL2 if GICv3 doesn't support v2 compatibilityMarc Zyngier
We currently access ICC_SRE_EL2 at each load/put on VHE, and on each entry/exit on nVHE. Both are quite onerous on NV, as this register always traps. We do this to make sure the EL1 guest doesn't flip between v2 and v3 behind our back. But all modern implementations have dropped v2, and this is just overhead. At the same time, the GICv5 spec has been fixed to allow access to ICC_SRE_EL2 in legacy mode. Use this opportunity to replace the GICv5 checks for v2 compat checks, with an ad-hoc static key. Co-developed-by: Sascha Bischoff <sascha.bischoff@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Fix page leak in user_mem_abort()Fuad Tabba
The user_mem_abort() function acquires a page reference via __kvm_faultin_pfn() early in its execution. However, the subsequent checks for mismatched attributes between stage 1 and stage 2 mappings would return an error code directly, bypassing the corresponding page release. Fix this by storing the error and releasing the unused page before returning the error. Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings") Fixes: 2a8dfab26677 ("KVM: arm64: Block cacheable PFNMAP mapping") Signed-off-by: Fuad Tabba <tabba@google.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org
2025-09-17Merge branch kvm-arm64/dump-instr into kvmarm-master/nextMarc Zyngier
* kvm-arm64/dump-instr: : . : Dump the isntruction stream on panic, just like the rest of the kernel : already does. : : Patches courtesy of Mostafa Saleh (20250909133631.3844423-1-smostafa@google.com) : . KVM: arm64: Map hyp text as RO and dump instr on panic KVM: arm64: Dump instruction on hyp panic Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17Merge branch kvm-arm64/mmio-rcu into kvmarm-master/nextMarc Zyngier
* kvm-arm64/mmio-rcu: : . : Speed up MMIO registration by avoiding unnecessary RCU synchronisation, : courtesy of Keir Fraser (20250909100007.3136249-1-keirf@google.com). : . KVM: Avoid synchronize_srcu() in kvm_io_bus_register_dev() KVM: Implement barriers before accessing kvm->buses[] on SRCU read paths KVM: arm64: vgic: Explicitly implement vgic_dist::ready ordering KVM: arm64: vgic-init: Remove vgic_ready() macro Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17KVM: arm64: Fix kvm_vcpu_{set,is}_be() to deal with EL2 stateMarc Zyngier
Nobody really cares about BE, but KVM currently only deals with SCTLR_EL1 when evaluating or setting the endianness in PSCI, meaning that we evaluate whatever the L2 state has been at some point. Teach these primitives about SCTLR_EL2, and forget about BE... Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-09-17arm64: dts: qcom: ipq5018: add QUP1 UART2 nodeManikanta Mylavarapu
Add node to support the second UART node controller in IPQ5018. Signed-off-by: Manikanta Mylavarapu <quic_mmanikan@quicinc.com> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20250917-ipq5018-uart2-v1-1-f8680bbf947f@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17arm64: dts: qcom: lemans: Flatten usb controller nodesKrishna Kurapati
Flatten usb controller nodes and update to using latest bindings and flattened driver approach. Enumeration of ADB has been tested on EVK Platform. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250917123827.671966-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-17x86/sev: Add new dump_rmp parameter to snp_leak_pages() APIAshish Kalra
When leaking certain page types, such as Hypervisor Fixed (HV_FIXED) pages, it does not make sense to dump RMP contents for the 2MB range of the page(s) being leaked. In the case of HV_FIXED pages, this is not an error situation where the surrounding 2MB page RMP entries can provide debug information. Add new __snp_leak_pages() API with dump_rmp bool parameter to support continue adding pages to the snp_leaked_pages_list but not issue dump_rmpentry(). Make snp_leak_pages() a wrapper for the common case which also allows existing users to continue to dump RMP entries. Suggested-by: Thomas Lendacky <Thomas.Lendacky@amd.com> Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/cover.1758057691.git.ashish.kalra@amd.com
2025-09-17x86/cpu/topology: Define AMD64_CPUID_EXT_FEAT MSRK Prateek Nayak
Add defines for the 0xc001_1005 MSR (Core::X86::Msr::CPUID_ExtFeatures) used to toggle the extended CPUID features, instead of using literal numbers. Also define and use the bits necessary for an old TOPOEXT fixup on AMD Family 0x15 processors. No functional changes intended. [ bp: Massage, rename MSR to adhere to the documentation name. ] Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/20250901170418.4314-1-kprateek.nayak@amd.com
2025-09-17x86/cpu/topology: Check for X86_FEATURE_XTOPOLOGY instead of passing ↵K Prateek Nayak
has_xtopology cpu_parse_topology_ext() sets X86_FEATURE_XTOPOLOGY before returning true if any of the XTOPOLOGY leaf (0x80000026 / 0xb) could be parsed successfully. Instead of storing and passing around this return value using "has_xtopology" in parse_topology_amd(), check for X86_FEATURE_XTOPOLOGY directly in parse_8000_001e() to simplify the flow. No functional changes intended. Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/20250901170418.4314-1-kprateek.nayak@amd.com
2025-09-17x86/cpu/cacheinfo: Simplify cacheinfo_amd_init_llc_id() using _cpuid4_infoK Prateek Nayak
struct _cpuid4_info has the same layout as the CPUID leaf 0x8000001d. Use the encoded definition and amd_fill_cpuid4_info(), get_cache_id() helpers instead of open coding masks and shifts to calculate the llc_id. cacheinfo_amd_init_llc_id() is only called on AMD systems that support X86_FEATURE_TOPOEXT and amd_fill_cpuid4_info() uses the information from CPUID leaf 0x8000001d on all these systems which is consistent with the current open coded implementation. While at it, avoid reading cpu_data() every time get_cache_id() is called and instead pass the APIC ID necessary to return the _cpuid4_info.id from get_cache_id(). No functional changes intended. [ bp: do what Ahmed suggests: merge into one patch, make id4 ptr const. ] Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Ahmed S. Darwish <darwi@linutronix.de> Link: https://lore.kernel.org/20250821051910.7351-2-kprateek.nayak@amd.com
2025-09-17x86/cpu: Rename and move CPU model entry for Diamond RapidsTony Luck
This model was added as INTEL_PANTHERCOVE_X (based on the name of the core) with a comment that the platform name is Diamond Rapids. It was also placed at the end of the file in a new section for family 19 processors. This is different from previous naming as Andrew Cooper noted. PeterZ agreed and posted a patch[1] to fix the name and move it in sequence with other Xeon servers. But without a commit description or sign-off the patch wasn't ever applied. Patch updated to cover one additional use of the #define by turbostat and to change the "Family 6" comment to also list 18 and 19 since new models in these families are mixed in with family 6. Originally-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Link: https://lore.kernel.org/all/20250214130205.GK14028@noisy.programming.kicks-ass.net/ # [1]
2025-09-17dts: sophgo: sg2042: added numa id descriptionHan Gao
According to the description of [1], sg2042 is divided into 4 numa. STREAM test performance will improve. Before: Function Best Rate MB/s Avg time Min time Max time Copy: 10739.7 0.015687 0.014898 0.016385 Scale: 10865.9 0.015628 0.014725 0.016757 Add: 10622.3 0.023276 0.022594 0.023899 Triad: 10583.4 0.023653 0.022677 0.024761 After: Function Best Rate MB/s Avg time Min time Max time Copy: 34254.9 0.005142 0.004671 0.005995 Scale: 37735.5 0.004752 0.004240 0.005407 Add: 44206.8 0.005983 0.005429 0.006461 Triad: 43040.6 0.006320 0.005576 0.006996 [1] https://github.com/sophgo/sophgo-doc/blob/main/SG2042/TRM/source/pic/mesh.png Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/20250910105531.519897-1-rabenda.cn@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-09-17riscv: Use generic TIF bitsThomas Gleixner
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by RISCV. So no further action required here. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2025-09-17loongarch: Use generic TIF bitsThomas Gleixner
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by loongarch. So no further action required here. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2025-09-17s390/entry: Remove unused TIF flagsSven Schnelle
The conversion of s390 to generic entry missed to remove the TIF_SYSCALL*/TIF_SECCOMP flags. Remove them as they are unused now. Fixes: 56e62a737028 ("s390: convert to generic entry") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com>
2025-09-17s390: Use generic TIF bitsThomas Gleixner
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by s390. So no further action required here. This leaves a comment about the AUDIT/TRACE/SECCOMP bits which are handled by SYSCALL_WORK in the generic code, so they seem redundant, but that's a problem for the s390 wizards to think about. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Heiko Carstens <hca@linux.ibm.com>
2025-09-17x86: Use generic TIF bitsThomas Gleixner
No point in defining generic items and the upcoming RSEQ optimizations are only available with this _and_ the generic entry infrastructure, which is already used by x86. So no further action required here. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
2025-09-17asm-generic: Provide generic TIF infrastructureThomas Gleixner
Common TIF bits do not have to be defined by every architecture. They can be defined in a generic header. That allows adding generic TIF bits without chasing a gazillion of architecture headers, which is again a unjustified burden on anyone who works on generic infrastructure as it always needs a boat load of work to keep existing architecture code working when adding new stuff. While it is not as horrible as the ignorance of the generic entry infrastructure, it is a welcome mechanism to make architecture people rethink their approach of just leaching generic improvements into architecture code and thereby making it accumulatingly harder to maintain and improve generic code. It's about time that this changes. Provide the infrastructure and split the TIF space in half, 16 generic and 16 architecture specific bits. This could probably be extended by TIF_SINGLESTEP and BLOCKSTEP, but those are only used in architecture specific code. So leave them alone for now. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_ITYPE_IMMNam Cao
Use RV_EXTRACT_ITYPE_IMM, instead of re-implementing it in simulate_jalr(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/8ae34e966c312ae5cf6c09a35ddc290cce942208.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_UTYPE_IMMNam Cao
Use RV_EXTRACT_UTYPE_IMM, instead of reimplementing it in simulate_auipc(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/8f0defce9f1f23f1b44bb9750ed083cfc124213c.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_RD_REGNam Cao
Use RV_EXTRACT_RD_REG, instead of reimplementing its code. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/b31e5b41df5839a76103348e54dc034c8a43447a.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RVC_EXTRACT_BTYPE_IMMNam Cao
Use RVC_EXTRACT_BTYPE_IMM, instead of reimplementing it in simulate_c_bnez_beqz(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/8a8ed970f279fa5f24c90d840c2130e37bc6d16e.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RVC_EXTRACT_C2_RS1_REGNam Cao
Use RVC_EXTRACT_C2_RS1_REG, instead of reimplementing it in simulate_c_jr_jalr(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/d56955cd683411c6d2f63d13c78e0572462a3269.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RVC_EXTRACT_JTYPE_IMMNam Cao
Use RVC_EXTRACT_JTYPE_IMM, instead of reimplementing it in simulate_c_j(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/24497deaab06d6b12cb84923606ec26f67e25424.1747215274.git.namcao@linutronix.de/ [pjw@kernel.org: fixed subject line typo] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_BTYPE_IMMNam Cao
Use RV_EXTRACT_BTYPE_IMM, instead of reimplementing it in simulate_branch(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/b441038c991da11a7a48ea7140ab00e3bb119387.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_RS1_REGNam Cao
Use RV_EXTRACT_RS1_REG instead of reimplementing its code. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/b441038c991da11a7a48ea7140ab00e3bb119387.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Remove duplication of RV_EXTRACT_JTYPE_IMMNam Cao
Use RV_EXTRACT_JTYPE_IMM, instead of reimplementing it in simulate_jal(). Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/af502036738d381c6bdb96a236d21bab8c343f74.1747215274.git.namcao@linutronix.de/ Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Move branch_funct3 to insn.hNam Cao
Similar to other instruction-processing macros/functions, branch_funct3 should be in insn.h. Move it into insn.h as RV_EXTRACT_FUNCT3. This new name matches the style in insn.h. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/200c29a26338f19d09963fa02562787e8cfa06f2.1747215274.git.namcao@linutronix.de/ [pjw@kernel.org: updated to use RV_X_MASK and to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: kprobes: Move branch_rs2_idx to insn.hNam Cao
Similar to other instruction-processing macros/functions, branch_rs2_idx should be in insn.h. Move it into insn.h as RV_EXTRACT_RS2_REG. This new name matches the style in insn.h. Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/linux-riscv/107d4a6c1818bf169be2407b273a0483e6d55bbb.1747215274.git.namcao@linutronix.de/ [pjw@kernel.org: updated to use RV_X_MASK and to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Move all duplicate insn parsing macros into asm/insn.hAlexandre Ghiti
kernel/traps_misaligned.c and kvm/vcpu_insn.c define the same macros to extract information from the instructions. Let's move the definitions into asm/insn.h to avoid this duplication. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/20250620-dev-alex-insn_duplicate_v5_manual-v5-3-d865dc9ad180@rivosinc.com [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Strengthen duplicate and inconsistent definition of RV_X()Alexandre Ghiti
RV_X() macro is defined in two different ways which is error prone. So harmonize its first definition and add another macro RV_X_MASK() for the second one. Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250620-dev-alex-insn_duplicate_v5_manual-v5-2-d865dc9ad180@rivosinc.com [pjw@kernel.org: upcase the macro name to conform with previous practice] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Fix typo EXRACT -> EXTRACTAlexandre Ghiti
Simply fix a typo. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/20250620-dev-alex-insn_duplicate_v5_manual-v5-1-d865dc9ad180@rivosinc.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16riscv: Add kprobes KUnit testNam Cao
Add KUnit test for riscv kprobes, mostly for simulated instructions. The test install kprobes into multiple sample functions, and check that these functions still return the expected magic value. This test can detect some kprobe bugs reported in the past (in Link:). Link: https://lore.kernel.org/linux-riscv/20241119111056.2554419-1-namcao@linutronix.de/ Link: https://lore.kernel.org/stable/c7e463c0-8cad-4f4e-addd-195c06b7b6de@iscas.ac.cn/ Link: https://lore.kernel.org/linux-riscv/20230829182500.61875-1-namcaov@gmail.com/ Signed-off-by: Nam Cao <namcao@linutronix.de> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250513151631.3520793-1-namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-28 16:21:20 +0000