summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-09-17riscv: kprobes: Remove duplication of RV_EXTRACT_BTYPE_IMMNam Cao1-10/+1
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-17riscv: kprobes: Remove duplication of RV_EXTRACT_RS1_REGNam Cao1-5/+2
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-17riscv: kprobes: Remove duplication of RV_EXTRACT_JTYPE_IMMNam Cao1-6/+3
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-17riscv: kprobes: Move branch_funct3 to insn.hNam Cao2-4/+6
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-17riscv: kprobes: Move branch_rs2_idx to insn.hNam Cao2-4/+6
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-17riscv: Move all duplicate insn parsing macros into asm/insn.hAlexandre Ghiti3-273/+166
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-17riscv: Strengthen duplicate and inconsistent definition of RV_X()Alexandre Ghiti4-22/+23
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-17riscv: Fix typo EXRACT -> EXTRACTAlexandre Ghiti2-2/+2
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-17riscv: Add kprobes KUnit testNam Cao6-0/+323
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>
2025-09-17riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-uapi headersThomas Huth31-71/+71
While the GCC and Clang compilers already define __ASSEMBLER__ automatically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. So let's standardize on the __ASSEMBLER__ macro that is provided by the compilers now. This originally was a completely mechanical patch (done with a simple "sed -i" statement), with some manual fixups during rebasing of the patch later. Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: linux-riscv@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250606070952.498274-3-thuth@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-17riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headersThomas Huth3-5/+5
__ASSEMBLY__ is only defined by the Makefile of the kernel, so this is not really useful for uapi headers (unless the userspace Makefile defines it, too). Let's switch to __ASSEMBLER__ which gets set automatically by the compiler when compiling assembly code. This is a completely mechanical patch (done with a simple "sed -i" statement). Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: linux-riscv@lists.infradead.org Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250606070952.498274-2-thuth@redhat.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-17riscv: introduce ioremap_wc()Yunhui Cui2-0/+5
Compared with IO attributes, NC attributes can improve performance, specifically in these aspects: Relaxed Order, Gathering, Supports Read Speculation, Supports Unaligned Access. Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Signed-off-by: Qingfang Deng <qingfang.deng@siflower.com.cn> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250722091504.45974-2-cuiyunhui@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-16arm64: Kconfig: Remove GCS restrictions on UPROBESJeremy Linton1-1/+0
Now that the uprobe paths have been made GCS compatible drop the Kconfig restriction. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: uprobes: Add GCS support to uretprobesJeremy Linton1-0/+33
Ret probes work by changing the value in the link register at the probe location to return to the probe rather than the calling routine. Thus the GCS needs to be updated with this address as well. Since its possible to insert probes at locations where the current value of the LR doesn't match the GCS state this needs to be detected and handled in order to maintain the existing no-fault behavior. Co-developed-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Steve Capper <steve.capper@arm.com> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> [will: Add '__force' to gcspr casts in arch_uretprobe_hijack_return_addr()] Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: probes: Add GCS support to bl/blr/retJeremy Linton1-9/+35
The arm64 probe simulation doesn't currently have logic in place to deal with GCS and this results in core dumps if probes are inserted at control flow locations. Fix-up bl, blr and ret to manipulate the shadow stack as needed. While we manipulate and validate the shadow stack correctly, the hardware provides additional security by only allowing GCS operations against pages which are marked to support GCS. For writing there is gcssttr() which enforces this, but there isn't an equivalent for reading. This means that uprobe users should be aware that probing on control flow instructions which require reading the shadow stack (ex: ret) offers lower security guarantees than what is achieved without the uprobe active. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: uaccess: Add additional userspace GCS accessorsJeremy Linton1-0/+54
Uprobes need more advanced read, push, and pop userspace GCS functionality. Implement those features using the existing gcsstr() and copy_from_user(). Its important to note that GCS pages can be read by normal instructions, but the hardware validates that pages used by GCS specific operations, have a GCS privilege set. We aren't validating this in load_user_gcs because it requires stabilizing the VMA over the read which may fault. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> [will: Add '__force' to gcspr cast in pop_user_gcs()] Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64/fpsimd: simplify sme_setup()Yury Norov (NVIDIA)1-2/+3
The function checks info->vq_map for emptiness right before calling find_last_bit(). We can use the find_last_bit() output and save on bitmap_empty() call, which is O(N). Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: qcs615: Enable TSENS support for QCS615 SoCGaurav Kohli1-1/+205
Add TSENS and thermal devicetree node for QCS615 SoC. Signed-off-by: Gaurav Kohli <quic_gkohli@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250702082311.4123461-3-quic_gkohli@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16KVM: x86: hyper-v: Use guard() instead of mutex_lock() to simplify codeLiao Yuanhong1-7/+5
Use guard(mutex) instead of mutex_lock/mutex_unlock pair to simplify the error handling when setting up the TSC page for a Hyper-V guest. No functional change intended. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250901131604.646415-1-liaoyuanhong@vivo.com [sean: tweak changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16KVM: x86: Use guard() instead of mutex_lock() to simplify codeLiao Yuanhong1-10/+7
Use guard(mutex) instead of mutex_lock/mutex_unlock pair to simplify the error handling when allocating the APIC access page. No functional change intended. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250901131822.647802-1-liaoyuanhong@vivo.com [sean: add blank link to isolate guard(), tweak changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16KVM: x86/pmu: Correct typo "_COUTNERS" to "_COUNTERS"Dapeng Mi2-7/+7
Fix typos. "_COUTNERS" -> "_COUNTERS". Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Tested-by: Yi Lai <yi1.lai@intel.com> Link: https://lore.kernel.org/r/20250718001905.196989-2-dapeng1.mi@linux.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16KVM: TDX: Reject fully in-kernel irqchip if EOIs are protected, i.e. for TDX VMsSagi Shahar3-0/+15
Reject KVM_CREATE_IRQCHIP if the VM type has protected EOIs, i.e. if KVM can't intercept EOI and thus can't faithfully emulate level-triggered interrupts that are routed through the I/O APIC. For TDX VMs, the TDX-Module owns the VMX EOI-bitmap and configures all IRQ vectors to have the CPU accelerate EOIs, i.e. doesn't allow KVM to intercept any EOIs. KVM already requires a split irqchip[1], but does so during vCPU creation, which is both too late to allow userspace to fallback to a split irqchip and a less-than-stellar experience for userspace since an -EINVAL on KVM_VCPU_CREATE is far harder to debug/triage than failure exactly on KVM_CREATE_IRQCHIP. And of course, allowing an action that ultimately fails is arguably a bug regardless of the impact on userspace. Link: https://lore.kernel.org/lkml/20250222014757.897978-11-binbin.wu@linux.intel.com [1] Link: https://lore.kernel.org/lkml/aK3vZ5HuKKeFuuM4@google.com Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Sagi Shahar <sagis@google.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com> Acked-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/r/20250827011726.2451115-1-sagis@google.com [sean: massage shortlog+changelog, relocate setting has_protected_eoi] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-09-16arm64/Kconfig: Remove CONFIG_RODATA_FULL_DEFAULT_ENABLEDHuang Shijie2-15/+1
Now that 'rodata=full' has been removed in favour of parity with x86, CONFIG_RODATA_FULL_DEFAULT_ENABLED no longer serves a useful purpose. Remove it. Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Rework the 'rodata=' optionsHuang Shijie1-2/+2
As per admin guide documentation, "rodata=on" should be the default on platforms. Documentation/admin-guide/kernel-parameters.txt describes these options as rodata= [KNL,EARLY] on Mark read-only kernel memory as read-only (default). off Leave read-only kernel memory writable for debugging. full Mark read-only kernel memory and aliases as read-only [arm64] But on arm64 platform, RODATA_FULL_DEFAULT_ENABLED is enabled by default, so "rodata=full" is the default instead. For parity with other architectures, namely x86, rework 'rodata=on' to match the current "full" behaviour and replace 'rodata=full' with a new 'rodata=noalias' option which retains writable aliases in the direct map for memory regions outside of the kernel image. Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Represent physical memory with phys_addr_t and resource_size_tSam Edwards5-36/+42
This is a type-correctness cleanup to MMU/boot code that replaces several instances of void * and u64 with phys_addr_t (to represent addresses) and resource_size_t (to represent sizes) to emphasize that the code in question concerns physical memory specifically. The rationale for this change is to improve clarity and readability in a few modules that handle both types (physical and virtual) of address and differentiation is essential. I have left u64 in cases where the address may be either physical or virtual, where the address is exclusively virtual but used in heavy pointer arithmetic, and in cases I may have overlooked. I do not necessarily consider u64 the ideal type in those situations, but it avoids breaking existing semantics in this cleanup. This patch provably has no effect at runtime: I have verified that .text of vmlinux is identical after this change. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Make map_fdt() return mapped pointerSam Edwards1-6/+7
Currently map_fdt() accepts a physical address and relies on the caller to keep using the same value after mapping, since the implementation happens to install an identity mapping. This obscures the fact that the usable pointer is defined by the mapping, not by the input value. Since the mapping determines pointer validity, it is more natural to produce the pointer at mapping time. Change map_fdt() to return a void * pointing to the mapped FDT. This clarifies the data flow, removes the implicit identity assumption, and prepares for making map_fdt() accept a phys_addr_t in a follow-up change. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: mm: Cast start/end markers to char *, not u64Sam Edwards1-3/+3
There are a few memset() calls in map_kernel.c that cast marker-symbol addresses to u64 in order to perform pointer subtraction (range size computation). Cast them with (char *) instead, aligning with idiomatic C pointer arithmetic. This patch provably has no effect at runtime: I have verified that .text of vmlinux is identical after this change. Signed-off-by: Sam Edwards <CFSworks@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: sdm845-enchilada: Add notification LEDAntonio Rische1-0/+28
Add the notification LED for the device. The R/G/B channels are controlled by the PMI8998 LPG. Signed-off-by: Antonio Rische <nt8r@protonmail.com> Signed-off-by: David Heidelberg <david@ixit.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250904-enchilada-led-v1-1-dcf936ea7795@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: apq8016-sbc: Drop redundant HDMI bridge statusKrzysztof Kozlowski1-2/+0
New device nodes are enabled by default, so status is redundant. No functional impact, verified with dtx_diff. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250904084421.82985-4-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: apq8016-sbc: Correct HDMI bridge #sound-dai-cellsKrzysztof Kozlowski1-2/+2
HDMI bridge has only one sound DAI and bindings already expect that (dtbs_check): apq8016-sbc.dtb: bridge@39 (adi,adv7533): #sound-dai-cells: 0 was expected Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250904084421.82985-3-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16riscv: dts: starfive: add Milk-V Mars CM Lite system-on-moduleE Shattow2-0/+26
Milk-V Mars CM Lite is a System-on-Module based on the Milk-V Mars CM without the onboard eMMC storage component populated and configured instead for SD3.0 Card Slot on that interface via 100-pin connector. Link to Milk-V Mars CM Lite schematics: https://github.com/milkv-mars/mars-files/tree/main/Mars-CM_Hardware_Schematices Link to StarFive JH7110 Technical Reference Manual: https://doc-en.rvspace.org/JH7110/TRM/index.html Link to Raspberry Pi CM4IO datasheet: https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Add the devicetree file to make use of StarFive JH7110 common supported features PMIC, EEPROM, UART, I2C, GPIO, PCIe, QSPI Flash, PWM, and Ethernet. Also configure the eMMC interface mmc0 for SD Card use and configure the common SD Card interface mmc1 for onboard SDIO BT+WiFi. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-09-16riscv: dts: starfive: add Milk-V Mars CM system-on-moduleE Shattow2-0/+13
Milk-V Mars CM is a System-on-Module based on the StarFive VisionFive 2 board and Radxa CM3 System-on-Module compatible with the Raspberry Pi CM4IO Classic IO Board. Mars CM SoM features: - StarFive JH7110 System on Chip with RV64GC up to 1.5GHz - AXP15060 Power Management Unit - LPDDR4 2GB / 4GB / 8GB DRAM memory - BL24C04F 4K bits (512 x 8) EEPROM - GigaDevice 25LQ128EWIG QSPI NOR Flash 16M or SoC ROM UART loader for boot (selectable by GPIO) - eMMC5.0 8GB / 16GB / 32GB flash storage onboard - AP6256 via SDIO 2.0 onboard wireless connectivity WiFi 5 + Bluetooth 5.2 (optional, present in models with WiFi feature) - 1x Motorcomm YT8531C Gigabit Ethernet PHY - IMG BXE-4-32 Integrated GPU with 3D Acceleration: - H.264 & H.265 4K@60fps Decoding - H.265 1080p@30fps Encoding - JPEG encoder / decoder Additional features available via 2x 100-pin connectors for CM4IO Board: - 1x HDMI 2.0 - 1x MIPI DSI (4-lanes) - 1x 2CH Audio out (via GPIO) - 1x MIPI CSI (2x2-lanes or 1x4-lanes) - 1x USB 2.0 - 1x PCIe 1-lane Host, Gen 2 (5Gbps) - Up to 28x GPIO, supporting 3.3V - UART x6 - PWM x8 - I2C x7 - SPI - I2S Link to Milk-V Mars CM schematics: https://github.com/milkv-mars/mars-files/tree/main/Mars-CM_Hardware_Schematices Link to StarFive JH7110 Technical Reference Manual: https://doc-en.rvspace.org/JH7110/TRM/index.html Link to Raspberry Pi CM4IO datasheet: https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Add the devicetree file to make use of StarFive JH7110 common supported features PMIC, EEPROM, UART, I2C, GPIO, eMMC, PCIe, QSPI Flash, PWM, and Ethernet. Also configure the common SD Card interface mmc1 for onboard SDIO BT+WiFi. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-09-16riscv: dts: starfive: add common board dtsi for Milk-V Mars CM variantsE Shattow1-0/+159
Add a common board dtsi for use by Milk-V Mars CM and Milk-V Mars CM Lite. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-09-16arm64: uaccess: Move existing GCS accessors definitions to gcs.hJeremy Linton2-41/+36
We are going to add some additional GCS access helpers to gcs.h in order to avoid some forward reference problems with uaccess. In preparation for that, lets move the existing gcssttr() and put_user_gcs() routines into gcs.h where it makes sense to keep all the accessors together. Further, the code which uses them already includes gcs.h and there is an existing CONFIG_ARM64_GCS check we can reuse. The GCSSTTR instruction description comment is corrected during the move. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: probes: Break ret out from bl/blrJeremy Linton3-5/+15
Prepare for GCS by breaking RET out into its own function, where it makes more sense to encapsulate the new behavior independent from the branch instructions. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: lemans: Add PCIe lane equalization preset propertiesZiyue Zhang1-0/+6
Add PCIe lane equalization preset properties with all values set to 5 for 8.0 GT/s and 16.0 GT/s data rates to enhance link stability. Co-developed-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://lore.kernel.org/r/20250904065225.1762793-4-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64/hwcap: Add hwcap for FEAT_LSFEMark Brown4-0/+5
FEAT_LSFE (Large System Float Extension), providing atomic floating point memory operations, is optional from v9.5. This feature adds no new architectural stare and we have no immediate use for it in the kernel so simply provide a hwcap for it to support discovery by userspace. Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2025-09-16arm64: dts: qcom: sm8450: enable camera clock controller by defaultVladimir Zapolskiy1-1/+0
Enable camera clock controller on Qualcomm SM8450 boards by default due to a reasonable agreement of having all clock controllers enabled. Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250909235547.787396-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: qcm2290: Add CCI nodeLoic Poulain1-0/+50
Add Camera Control Interface (CCI), supporting two I2C masters. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250911212102.470886-2-loic.poulain@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Add IMX577-based camera overlayWenmeng Liu2-0/+101
Enable IMX577 via CCI1 on LeMans EVK Core Kit. The LeMans EVK board does not include a camera sensor by default, this overlay reflects the possibility of attaching an optional camera sensor. For this reason, the camera sensor configuration is placed in lemans-evk-camera.dtso, rather than modifying the base lemans-evk.dts. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <quic_wenmliu@qualcomm.com> Link: https://lore.kernel.org/r/20250912-camss_rb8-v6-3-c9a6c3d67392@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans: Add CCI definitionsWenmeng Liu1-0/+268
Qualcomm SA8775P SoC contains 4 Camera Control Interface controllers. Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wenmeng Liu <quic_wenmliu@qualcomm.com> Link: https://lore.kernel.org/r/20250912-camss_rb8-v6-2-c9a6c3d67392@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16MIPS: PCI: Use pci_enable_resources()Ilpo Järvinen1-36/+2
pci-legacy.c under MIPS has a copy of pci_enable_resources() named as pcibios_enable_resources(). Having own copy of same functionality could lead to inconsistencies in behavior, especially now as pci_enable_resources() and the bridge window resource flags behavior are going to be altered by upcoming changes. The check for !r->start && r->end is already covered by the more generic checks done in pci_enable_resources(). Call pci_enable_resources() from MIPS's pcibios_enable_device() and remove pcibios_enable_resources(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Link: https://patch.msgid.link/20250829131113.36754-4-ilpo.jarvinen@linux.intel.com
2025-09-16sparc/PCI: Remove pcibios_enable_device() as they do nothing extraIlpo Järvinen3-81/+0
Under arch/sparc/ there are multiple copies of pcibios_enable_device() but none of those seem to do anything extra beyond what pci_enable_resources() is supposed to do. These functions could lead to inconsistencies in behavior, especially now as pci_enable_resources() and the bridge window resource flags behavior are going to be altered by upcoming changes. Remove all pcibios_enable_device() from arch/sparc/ so that PCI core can simply call into pci_enable_resources() instead using its __weak version of pcibios_enable_device(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250829131113.36754-3-ilpo.jarvinen@linux.intel.com
2025-09-16m68k/PCI: Use pci_enable_resources() in pcibios_enable_device()Ilpo Järvinen1-28/+11
m68k has a resource enable (check) loop in its pcibios_enable_device() which for some reason differs from pci_enable_resources(). This could lead to inconsistencies in behavior, especially now as pci_enable_resources() and the bridge window resource flags behavior are going to be altered by upcoming changes. The check for !r->start && r->end is already covered by the more generic checks done in pci_enable_resources(). The entire pcibios_enable_device() suspiciously looks copy-paste from some other arch as also indicated by the preceding comment. However, it also enables PCI_COMMAND_IO | PCI_COMMAND_MEMORY always for bridges. It is not clear why that is being done as the commit e93a6bbeb5a5 ("m68k: common PCI support definitions and code") introducing this code states "Nothing specific to any PCI implementation in any m68k class CPU hardware yet". Replace the resource enable loop with a call to pci_enable_resources() and adjust the Command Register afterwards as it's unclear if that is necessary or not so keep it for now. Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250829131113.36754-2-ilpo.jarvinen@linux.intel.com
2025-09-16arm64: dts: qcom: lemans: Add support for camssVikram Sharma1-0/+185
Add changes to support the camera subsystem on the lemans. Co-developed-by: Suresh Vankadara <quic_svankada@quicinc.com> Signed-off-by: Suresh Vankadara <quic_svankada@quicinc.com> Signed-off-by: Vikram Sharma <quic_vikramsa@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250814101615.1102795-10-quic_vikramsa@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sdm845-starqltechn: add slpi supportDzmitry Sankouski1-0/+29
Add support for Qualcomm sensor low power island. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Link: https://lore.kernel.org/r/20250912-starqltechn_slpi-v2-2-5ca5ddbbe7b4@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sdm845-starqltechn: fix slpi reserved memDzmitry Sankouski1-1/+1
When adding adsp reserved mem, slpi reserved memory was shrunk according to vendor kernel log: `Removed memory: created DMA memory pool at 0x0000000096700000, size 15 M` However, kernel failed to load firmware with 15MiB reserved region: `[ 14.885885] qcom_q6v5_pas 5c00000.remoteproc: segment outside memory range` Increase slpi reserved region to 16MiB. Fixes: 58782c229e3e ("arm64: dts: qcom: sdm845-starqltechn: add initial sound support") Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250912-starqltechn_slpi-v2-1-5ca5ddbbe7b4@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: add initial support for Samsung Galaxy S22Eric Gonçalves2-0/+146
Add new device support for the Samsung Galaxy S22 (SM-S901E) phone What works: - SimpleFB - USB Signed-off-by: Eric Gonçalves <ghatto404@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250912202603.7312-2-ghatto404@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: qcs8300: Flatten usb controller nodesKrishna Kurapati3-61/+40
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> Link: https://lore.kernel.org/r/20250913182318.3547789-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1-hp-x14: Add support for X1P42100 HP Omnibook X14Jens Glathe2-0/+35
These laptops are the same as the already known 14-fe0xxx models, but with a Purwa SoC, SKU number 14-fe1xxx. [1] The supported features are the same as for the original Omnibook X14: - Keyboard (no function keys though) - Display - PWM brightness control - Touchpad - Touchscreen - PCIe ports (pcie4, pcie6a) - USB type-c, type-a - WCN6855 Wifi-6E - WCN6855 Bluetooth - ADSP and CDSP - X1 GPU - GPIO Keys (Lid switch) - Audio definition (works via USB and with internal speakers) [1]: https://www.hp.com/us-en/shop/pdp/hp-omnibook-x-laptop-next-gen-ai-pc-14-fe100-14-a4nd1av-1#techSpecs Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-3-fa457ca30ffe@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-09 05:54:45 +0300