summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-06-20KVM: VMX: Extract checking of guest's DEBUGCTL into helperSean Christopherson
Move VMX's logic to check DEBUGCTL values into a standalone helper so that the code can be used by nested VM-Enter to apply the same logic to the value being loaded from vmcs12. KVM needs to explicitly check vmcs12->guest_ia32_debugctl on nested VM-Enter, as hardware may support features that KVM does not, i.e. relying on hardware to detect invalid guest state will result in false negatives. Unfortunately, that means applying KVM's funky suppression of BTF and LBR to vmcs12 so as not to break existing guests. No functional change intended. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://lore.kernel.org/r/20250610232010.162191-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-20KVM: VMX: Allow guest to set DEBUGCTL.RTM_DEBUG if RTM is supportedSean Christopherson
Let the guest set DEBUGCTL.RTM_DEBUG if RTM is supported according to the guest CPUID model, as debug support is supposed to be available if RTM is supported, and there are no known downsides to letting the guest debug RTM aborts. Note, there are no known bug reports related to RTM_DEBUG, the primary motivation is to reduce the probability of breaking existing guests when a future change adds a missing consistency check on vmcs12.GUEST_DEBUGCTL (KVM currently lets L2 run with whatever hardware supports; whoops). Note #2, KVM already emulates DR6.RTM, and doesn't restrict access to DR7.RTM. Fixes: 83c529151ab0 ("KVM: x86: expose Intel cpu new features (HLE, RTM) to guest") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250610232010.162191-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-20KVM: x86: Drop kvm_x86_ops.set_dr6() in favor of a new KVM_RUN flagSean Christopherson
Instruct vendor code to load the guest's DR6 into hardware via a new KVM_RUN flag, and remove kvm_x86_ops.set_dr6(), whose sole purpose was to load vcpu->arch.dr6 into hardware when DR6 can be read/written directly by the guest. Note, TDX already WARNs on any run_flag being set, i.e. will yell if KVM thinks DR6 needs to be reloaded. TDX vCPUs force KVM_DEBUGREG_AUTO_SWITCH and never clear the flag, i.e. should never observe KVM_RUN_LOAD_GUEST_DR6. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250610232010.162191-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-20KVM: x86: Convert vcpu_run()'s immediate exit param into a generic bitmapSean Christopherson
Convert kvm_x86_ops.vcpu_run()'s "force_immediate_exit" boolean parameter into an a generic bitmap so that similar "take action" information can be passed to vendor code without creating a pile of boolean parameters. This will allow dropping kvm_x86_ops.set_dr6() in favor of a new flag, and will also allow for adding similar functionality for re-loading debugctl in the active VMCS. Opportunistically massage the TDX WARN and comment to prepare for adding more run_flags, all of which are expected to be mutually exclusive with TDX, i.e. should be WARNed on. No functional change intended. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250610232010.162191-3-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-20KVM: TDX: Use kvm_arch_vcpu.host_debugctl to restore the host's DEBUGCTLSean Christopherson
Use the kvm_arch_vcpu.host_debugctl snapshot to restore DEBUGCTL after running a TD vCPU. The final TDX series rebase was mishandled, likely due to commit fb71c7959356 ("KVM: x86: Snapshot the host's DEBUGCTL in common x86") deleting the same line of code from vmx.h, i.e. creating a semantic conflict of sorts, but no syntactic conflict. Using the version in kvm_vcpu_arch picks up the ulong => u64 fix (which isn't relevant to TDX) as well as the IRQ fix from commit 189ecdb3e112 ("KVM: x86: Snapshot the host's DEBUGCTL after disabling IRQs"). Link: https://lore.kernel.org/all/20250307212053.2948340-10-pbonzini@redhat.com Cc: Adrian Hunter <adrian.hunter@intel.com> Fixes: 8af099037527 ("KVM: TDX: Save and restore IA32_DEBUGCTL") Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20250610232010.162191-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-06-20KVM: TDX: Report supported optional TDVMCALLs in TDX capabilitiesPaolo Bonzini
Allow userspace to advertise TDG.VP.VMCALL subfunctions that the kernel also supports. For each output register of GetTdVmCallInfo's leaf 1, add two fields to KVM_TDX_CAPABILITIES: one for kernel-supported TDVMCALLs (userspace can set those blindly) and one for user-supported TDVMCALLs (userspace can set those if it knows how to handle them). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-06-20KVM: TDX: Exit to userspace for SetupEventNotifyInterruptPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-06-20KVM: TDX: Exit to userspace for GetTdVmCallInfoBinbin Wu
Exit to userspace for TDG.VP.VMCALL<GetTdVmCallInfo> via KVM_EXIT_TDX, to allow userspace to provide information about the support of TDVMCALLs when r12 is 1 for the TDVMCALLs beyond the GHCI base API. GHCI spec defines the GHCI base TDVMCALLs: <GetTdVmCallInfo>, <MapGPA>, <ReportFatalError>, <Instruction.CPUID>, <#VE.RequestMMIO>, <Instruction.HLT>, <Instruction.IO>, <Instruction.RDMSR> and <Instruction.WRMSR>. They must be supported by VMM to support TDX guests. For GetTdVmCallInfo - When leaf (r12) to enumerate TDVMCALL functionality is set to 0, successful execution indicates all GHCI base TDVMCALLs listed above are supported. Update the KVM TDX document with the set of the GHCI base APIs. - When leaf (r12) to enumerate TDVMCALL functionality is set to 1, it indicates the TDX guest is querying the supported TDVMCALLs beyond the GHCI base TDVMCALLs. Exit to userspace to let userspace set the TDVMCALL sub-function bit(s) accordingly to the leaf outputs. KVM could set the TDVMCALL bit(s) supported by itself when the TDVMCALLs don't need support from userspace after returning from userspace and before entering guest. Currently, no such TDVMCALLs implemented, KVM just sets the values returned from userspace. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> [Adjust userspace API. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-06-20x86/efi: Move runtime service initialization to arch/x86Alexander Shishkin
The EFI call in start_kernel() is guarded by #ifdef CONFIG_X86. Move the thing to the arch_cpu_finalize_init() path on x86 and get rid of the #ifdef in start_kernel(). No functional change intended. Suggested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/all/20250620135325.3300848-5-kirill.shutemov%40linux.intel.com
2025-06-20KVM: TDX: Handle TDG.VP.VMCALL<GetQuote>Binbin Wu
Handle TDVMCALL for GetQuote to generate a TD-Quote. GetQuote is a doorbell-like interface used by TDX guests to request VMM to generate a TD-Quote signed by a service hosting TD-Quoting Enclave operating on the host. A TDX guest passes a TD Report (TDREPORT_STRUCT) in a shared-memory area as parameter. Host VMM can access it and queue the operation for a service hosting TD-Quoting enclave. When completed, the Quote is returned via the same shared-memory area. KVM only checks the GPA from the TDX guest has the shared-bit set and drops the shared-bit before exiting to userspace to avoid bleeding the shared-bit into KVM's exit ABI. KVM forwards the request to userspace VMM (e.g. QEMU) and userspace VMM queues the operation asynchronously. KVM sets the return code according to the 'ret' field set by userspace to notify the TDX guest whether the request has been queued successfully or not. When the request has been queued successfully, the TDX guest can poll the status field in the shared-memory area to check whether the Quote generation is completed or not. When completed, the generated Quote is returned via the same buffer. Add KVM_EXIT_TDX as a new exit reason to userspace. Userspace is required to handle the KVM exit reason as the initial support for TDX, by reentering KVM to ensure that the TDVMCALL is complete. While at it, add a note that KVM_EXIT_HYPERCALL also requires reentry with KVM_RUN. Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> Tested-by: Mikko Ylinen <mikko.ylinen@linux.intel.com> Acked-by: Kai Huang <kai.huang@intel.com> [Adjust userspace API. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-06-20KVM: TDX: Add new TDVMCALL status code for unsupported subfuncsBinbin Wu
Add the new TDVMCALL status code TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED and return it for unimplemented TDVMCALL subfunctions. Returning TDVMCALL_STATUS_INVALID_OPERAND when a subfunction is not implemented is vague because TDX guests can't tell the error is due to the subfunction is not supported or an invalid input of the subfunction. New GHCI spec adds TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED to avoid the ambiguity. Use it instead of TDVMCALL_STATUS_INVALID_OPERAND. Before the change, for common guest implementations, when a TDX guest receives TDVMCALL_STATUS_INVALID_OPERAND, it has two cases: 1. Some operand is invalid. It could change the operand to another value retry. 2. The subfunction is not supported. For case 1, an invalid operand usually means the guest implementation bug. Since the TDX guest can't tell which case is, the best practice for handling TDVMCALL_STATUS_INVALID_OPERAND is stopping calling such leaf, treating the failure as fatal if the TDVMCALL is essential or ignoring it if the TDVMCALL is optional. With this change, TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED could be sent to old TDX guest that do not know about it, but it is expected that the guest will make the same action as TDVMCALL_STATUS_INVALID_OPERAND. Currently, no known TDX guest checks TDVMCALL_STATUS_INVALID_OPERAND specifically; for example Linux just checks for success. Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> [Return it for untrapped KVM_HC_MAP_GPA_RANGE. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-06-20Merge tag 'kvm-riscv-fixes-6.16-1' of https://github.com/kvm-riscv/linux ↵Paolo Bonzini
into HEAD KVM/riscv fixes for 6.16, take #1 - Fix the size parameter check in SBI SFENCE calls - Don't treat SBI HFENCE calls as NOPs
2025-06-20Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "There's nothing major (even the vmalloc one is just suppressing a potential warning) but all worth having, nonetheless. - Suppress KASAN false positive in stack unwinding code - Drop redundant reset of the GCS state on exec() - Don't try to descend into a !present PMD when creating a huge vmap() entry at the PUD level - Fix a small typo in the arm64 booting Documentation" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth() arm64/gcs: Don't call gcs_free() during flush_gcs() arm64: Restrict pagetable teardown to avoid false warning docs: arm64: Fix ICC_SRE_EL2 register typo in booting.rst
2025-06-20arm64: dts: mediatek: mt8370: Enable gpu supportLouis-Alexis Eyraud
Add a new gpu node in mt8370.dtsi to enable support for the ARM Mali G57 MC2 GPU (Valhall-JM) found on the MT8370 SoC, using the Panfrost driver. On a Mediatek Genio 510 EVK board, the panfrost driver probed with the following message: ``` panfrost 13000000.gpu: clock rate = 390000000 panfrost 13000000.gpu: mali-g57 id 0x9093 major 0x0 minor 0x0 status 0x0 panfrost 13000000.gpu: features: 00000000,000019f7, issues: 00000003, 80000400 panfrost 13000000.gpu: Features: L2:0x08130206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002830 AS:0xff JS:0x7 panfrost 13000000.gpu: shader_present=0x5 l2_present=0x1 [drm] Initialized panfrost 1.3.0 for 13000000.gpu on minor 0 ``` Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250509-mt8370-enable-gpu-v6-5-2833888cb1d3@collabora.com
2025-06-20arm64: stacktrace: Implement arch_stack_walk_reliable()Song Liu
Add arch_stack_walk_reliable(), which will be used during kernel live patching to detect when threads have completed executing old versions of functions. Note that arch_stack_walk_reliable() only needs to guarantee that it returns an error code when it cannot provide a reliable stacktrace. It is not required to provide a reliable stacktrace in all scenarios so long as it returns said error code. At present we can only reliably unwind up to an exception boundary. In future we should be able to improve this with additional data from the compiler (e.g. sframe). Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20250320171559.3423224-2-song@kernel.org [ Mark: Simplify logic, clarify commit message ] Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andrea della Porta <andrea.porta@suse.com> Cc: Breno Leitao <leitao@debian.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Miroslav Benes <mbenes@suse.cz> Cc: Petr Mladek <pmladek@suse.com> Cc: Song Liu <song@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250521111000.2237470-3-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-06-20arm64: stacktrace: Check kretprobe_find_ret_addr() return valueMark Rutland
If kretprobe_find_ret_addr() fails to find the original return address, it returns 0. Check for this case so that a reliable stacktrace won't silently ignore it. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andrea della Porta <andrea.porta@suse.com> Cc: Breno Leitao <leitao@debian.org> Cc: Josh Poimboeuf <jpoimboe@kernel.org> Cc: Miroslav Benes <mbenes@suse.cz> Cc: Petr Mladek <pmladek@suse.com> Cc: Song Liu <song@kernel.org> Cc: Will Deacon <will@kernel.org> Reviewed-and-tested-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/r/20250521111000.2237470-2-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-06-20arm64/module: Use text-poke API for late relocations.Dylan Hatch
To enable late module patching, livepatch modules need to be able to apply some of their relocations well after being loaded. In this scenario however, the livepatch module text and data is already RX-only, so special treatment is needed to make the late relocations possible. To do this, use the text-poking API for these late relocations. This patch is partially based off commit 88fc078a7a8f6 ("x86/module: Use text_poke() for late relocations"). Signed-off-by: Dylan Hatch <dylanbhatch@google.com> Acked-by: Song Liu <song@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250603223417.3700218-1-dylanbhatch@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2025-06-20arm64: dts: rockchip: support camera module on Haikou Video Demo on PX30 ↵Quentin Schulz
Ringneck The Haikou Video Demo adapter has a proprietary connector for a camera module which has an OV5675 camera sensor and a companion DW9714 focus lens driver. This adds support for the camera module on PX30 Ringneck module fitted on a Haikou devkit with the Haikou Video Demo adapter. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250610-ringneck-haikou-video-demo-cam-v2-3-de1bf87e0732@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-20arm64: dts: rockchip: add label to first port of ISP on px30Quentin Schulz
This will make it slightly easier for Device Trees (and Overlays) to link the ISP controller to a video input such as a CSI camera while also bringing it closer to what's been done already for the DSI controller. Suggested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250610-ringneck-haikou-video-demo-cam-v2-2-de1bf87e0732@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-20arm64: dts: rockchip: fix endpoint dtc warning for PX30 ISPQuentin Schulz
dtc complains with the following message for DTSes which use the ISP: arch/arm64/boot/dts/rockchip/px30.dtsi:1272.19-1276.6: Warning (graph_child_address): /isp@ff4a0000/ports/port@0: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary Typically, it is expected from the device DTS(I) to update the SoC DTSI nodes if they have more than one endpoint, so let's assume there's only one endpoint in port@0 by default, instead of forcing board DTS(I)s to /delete-property/ address-cells and size-cells to make dtc happy. Because PX30 PP1516/EVB's endpoint@0 is the only endpoint and considering its parent node now has no address-cells property, dtc complains (same messages for PX30 EVB): arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #address-cells value arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #size-cells value arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size' arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size' arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#address-cells' is -1, must be 1 arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#size-cells' is -1, must be 0 arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (graph_child_address): Failed prerequisite 'graph_endpoint' so we fix that by removing the reg property. dtc still complains (same messages for PX30 EVB): arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-450.6: Warning (unit_address_vs_reg): /isp@ff4a0000/ports/port@0/endpoint@0: node has a unit name, but no reg or ranges property so we also remove the @0 suffix off the node name. Fixes: 8df7b4537dfb ("arm64: dts: rockchip: add isp node for px30") Fixes: 474a77395be2 ("arm64: dts: rockchip: hook up camera on px30-evb") Fixes: 56198acdbf0d ("arm64: dts: rockchip: add px30-pp1516 base dtsi and board variants") Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250610-ringneck-haikou-video-demo-cam-v2-1-de1bf87e0732@cherry.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-20Merge tag 'drm-misc-next-2025-06-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.17: UAPI Changes: - Add Task Information for the wedge API Cross-subsystem Changes: Core Changes: - Fix warnings related to export.h - fbdev: Make CONFIG_FIRMWARE_EDID available on all architectures - fence: Fix UAF issues - format-helper: Improve tests Driver Changes: - ivpu: Add turbo flag, Add Wildcat Lake Support - rz-du: Improve MIPI-DSI Support - vmwgfx: fence improvement Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250619-perfect-industrious-whippet-8ed3db@houat
2025-06-20arm64: dts: s32g: add RTC nodeCiprian Marian Costea
The RTC module on S32G2/S32G3 based SoCs is used as a wakeup source from system suspend. Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: Add DSPI entries for S32G platformsLarisa Grigore
S32G3 and S32G2 have the same 6 SPI devices, add the DT entries. Devices are all the same except spi0 has 8 chip selects instead of 5. Clock settings for the chip rely on ATF Firmware [1]. [1]: https://github.com/nxp-auto-linux/arm-trusted-firmware Co-developed-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by: Larisa Grigore <Larisa.Grigore@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: freescale: imx93-phyboard-segin: Set ethernet1 aliasPrimoz Fiser
Set ethernet1 alias to EQOS interface on phyBOARD-Segin-i.MX93 marking it the secondary networking interface. The primary ethernet0 interface is already set by the SoM include file (imx93-phycore-som.dtsi). Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: freescale: imx93-phycore-som: Move ethernet0 alias to SoMPrimoz Fiser
Move alias for ethernet0 interface to the phyCORE-i.MX93 SoM include file. The reason behind it is that the physical location of the PHY chip connected to FEC interface is on the SoM itself and alias thus belongs into the SoM device-tree. Consequently, it can be used by all boards based on the phyCORE-i.MX93 SoM (phyBOARD-Segin and phyBOARD-Nash). This also enables us to mark FEC interface as the primary / first for networking in the bootloader and systemd (predictable interface names). Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: tqma8mpql: Add EASRC supportAlexander Stein
Enable EASRC support in tlv320aic32x4 sound card. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: tqma8mnql: Add EASRC supportAlexander Stein
Enable EASRC support in tlv320aic32x4 sound card. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: freescale: Add the BOE av123z7m-n17 variant of the Moduline DisplayMaud Spierings
Add the BOE av123z7m-n17 variant of the Moduline Display, this variant comes with a 12.3" 1920x720 display. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: freescale: Add the BOE av101hdt-a10 variant of the Moduline DisplayMaud Spierings
Add the BOE av101hdt-a10 variant of the Moduline Display, this variant comes with a 10.1 1280x720 display with a touchscreen (not working in mainline). Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: freescale: Add the GOcontroll Moduline Display baseboardMaud Spierings
The Moduline Display platform is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. The base Moduline Display board includes a board-to-board connector with various busses to enable adding new display types required by the application. It includes 2 Moduline IO module slots, a simple mono codec/amplifier, a four channel adc, 2 CAN busses, an RTC and optional wifi/bluetooth. busses to the display adapter include: - 4 lane LVDS - 4 lane MIPI-DSI - 4 lane MIPI-CSI - HDMI 2.0a - USB 2.0 - I2S - I2C - SPI Also a couple of GPIO and PWM pins for controlling various ICs on the display adapter board. Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: freescale: add Ka-Ro Electronics tx8p-ml81 COMMaud Spierings
The Ka-Ro Electronics tx8p-ml81 is a COM based on the imx8mp SOC. It has 2 GB of ram and 8 GB of eMMC storage on board. Add it to enable boards based on this Module Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: imx8mp: Add pinctrl config definitionsMaud Spierings
Currently to configure each IOMUXC_SW_PAD_CTL_PAD the raw value of this register is written in the dts, these values are not obvious. Add defines which describe the fields of this register which can be or-ed together to produce readable settings. Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-06-20arm64: dts: rockchip: Add power controller for RK3528Jonas Karlman
Add power-domain nodes for the power controller on RK3528. Only PD_GPU can fully be powered down. PD_RKVDEC, PD_RKVENC, PD_VO and PD_VPU are idle only power domains used by miscellaneous devices. Because multiple of the miscellaneous device types currently complain about the use of a power-domains prop, only PD_GPU is enabled. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Link: https://lore.kernel.org/r/20250518220707.669515-5-jonas@kwiboo.se [changed to using numeric values, until the next merge-window] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: enable USB on Sige5Nicolas Frattaroli
The ArmSoM Sige5 has several USB ports: a Type-A USB 3 port (USB2 lines going through a hub), a Type-A USB 2.0 port (also going through a hub), a Type-C DC input port that has absolutely no USB data connection and a Type-C port with USB3.2 Gen1x1 that's also the maskrom programming port. Enable these ports, and set the device role to be host for the host ports. The data capable Type-C USB port uses a fusb302 for data role switching. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250619-rk3576-sige5-usb-v5-2-9069a7e750e1@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5Alexey Charkov
List both CPU supply regulators which drive the little and big CPU clusters, respectively, so that cpufreq can pick them up. Without this patch the cpufreq governor attempts to raise the big CPU frequency under high load, while its supply voltage stays at 850000 uV. This causes system instability and, in my case, random reboots. With this patch, supply voltages are adjusted in step with frequency changes from 700000-737000 uV in idle to 950000 uV under full load, and the system appears to be stable. While at this, list all CPU supplies for completeness. Cc: stable@vger.kernel.org Fixes: 40f742b07ab2 ("arm64: dts: rockchip: Add rk3576-armsom-sige5 board") Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250614-sige5-updates-v2-1-3bb31b02623c@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: add overlay for the WiFi/BT module on Sige5 v1.2Alexey Charkov
Add support for the Broadcom based WiFi/Bluetooth module (BW3752-50B1) found in ArmSoM Sige5 boards version 1.2. This includes SDIO connected WiFi with OOB interrupt support, as well as UART connected Bluetooth with its respective interrupts. PCM support for Bluetooth SCO audio is left out for now. It is connected to SAI2 in M0 pin mode in case someone needs to enable it. Note that v1.1 boards used a Realtek based module which is incompatible with these DT nodes, so v1.1 would need a different overlay. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250614-sige5-updates-v2-4-3bb31b02623c@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: add version-independent WiFi/BT nodes on Sige5Alexey Charkov
ArmSoM Sige5 uses a soldered-on WiFi/BT module with WiFi on SDIO and BT on UART. However, board v1.1 uses a Realtek based BL-M8852BS2, while v1.2 uses a Broadcom based BW3752-50B1. They use the same pins and controllers, but require different DT properties to enable. Thankfully, the WiFi part at least works without explicitly listing it in the device tree, albeit without OOB interrupt functionality. Add required device tree nodes that do not depend on the board version so that at least the WiFi module can appear on the SDIO bus. WiFi OOB interrupt and Bluetooth function support are not enabled here, as they require module specific properties. Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250614-sige5-updates-v2-3-3bb31b02623c@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: add SDIO controller on RK3576Alexey Charkov
RK3576 has one more SD/MMC controller than are currently listed in its .dtsi, with the missing one intended as an SDIO controller. Add the missing node (tested with the onboard WiFi module on ArmSoM Sige5 v1.2) Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250614-sige5-updates-v2-2-3bb31b02623c@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: Enable gpu on rk3576-evb1-v10Andy Yan
Enable gpu for rk3576 evb. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Link: https://lore.kernel.org/r/20250618063609.690332-1-andyshrk@163.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: rockchip: Update the PinePhone Pro panel descriptionOlivier Benjamin
Fix a few issues in the panel section of the PinePhone Pro DTS: - add the second part of the Himax HX8394 LCD panel controller compatible - as proposed by Diederik de Haas, reuse the mipi_out and ports definitions from rk3399-base.dtsi instead of redefining them - add a pinctrl for the LCD_RST signal for LCD1, derived from LCD1_RST, which is on GPIO4_D1, as documented on pages 11 and 16 of the PinePhone Pro schematic Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com> Reviewed-by: Diederik de Haas <didi.debian@cknow.org> Link: https://lore.kernel.org/r/20250619-dtb_fixes-v3-1-9cb02ddd8ce4@bootlin.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-06-19arm64: dts: renesas: rcar-gen3: Add bootph-all to sysinfo EEPROMsMarek Vasut
Add bootph-all property to sysinfo EEPROM on Renesas R-Car Gen3 Salvator-X(S), ULCB, Condor, Ebisu, Draak boards. The sysinfo EEPROM is used by U-Boot early on, mark it using the bootph-all property. No functional change for the Linux kernel, this only reduces the divergence of DTs between U-Boot and Linux. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250608215212.1619182-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: sparrow-hawk: Describe split PCIe clockMarek Vasut
The Sparrow Hawk board supplies the PCIe controller input clock and PCIe bus clock from separate outputs of the Renesas 9FGV0441 clock generator. Describe this split bus configuration in the board DT. The topology looks as follows: ____________ _____________ | R-Car PCIe | | PCIe device | | | | | | PCIe RX<|==================|>PCIe TX | | PCIe TX<|==================|>PCIe RX | | | | | | PCIe CLK<|======.. ..======|>PCIe CLK | '------------' || || '-------------' || || ____________ || || | 9FGV0441 | || || | | || || | CLK DIF0<|======'' || | CLK DIF1<|=========='' | CLK DIF2<| | CLK DIF3<| '------------' Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/20250607194541.79176-3-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r8a779g0: Describe PCIe root portsMarek Vasut
Add nodes which describe the root ports in the PCIe controller DT nodes. This can be used together with the pwrctrl driver to control clock and power supply to a PCIe slot. For example usage, refer to the Sparrow Hawk board. Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/20250607194541.79176-2-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: ebisu: Add CAN0 supportGeert Uytterhoeven
On R-Car E3, Classical CAN0/1 and CAN-FD share the same sets of pins, so only one of them can be used at the same time. Add support for using CAN0 instead of CAN-FD channel 0 on Ebisu. By default, only CAN-FD channel 0 is enabled, as before. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/612b999870dd64789041e4b0e9c568389b3fb95e.1749048320.git.geert+renesas@glider.be
2025-06-19ARM: dts: renesas: r9a06g032: Add second clock input to RTCWolfram Sang
The external RTC clock is populated on the RZ/N1D module, so describe it and add a reference to the RTC node. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250604084211.28090-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable USB2.0 supportLad Prabhakar
Enable USB2.0 support on the RZ/V2N EVK board, CN2 connector on the EVK supports host/function operation. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250528140453.181851-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r9a09g056: Add USB2.0 supportLad Prabhakar
The Renesas RZ/V2N (R9A09G056) SoC features a single-channel USB2.0 interface with host and peripheral (function) support. Add the ECHI, OHCI, USB2.0 PHY and reset control nodes for USB2.0 channel in R9A09G056 SoC DTSI. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250528140453.181851-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r8a779g3-sparrow-hawk: Sort DTSMarek Vasut
Sort DTS alphabetically. Fix up the placement of &rcar_sound {}. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250525160336.82960-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19ARM: dts: renesas: r9a06g032-rzn1d400-db: Describe debug LEDsWolfram Sang
Enable the debug LEDs connected via the I2C GPIO extender. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250522080112.26050-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2025-06-19arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable USB2.0 supportLad Prabhakar
Enable USB2.0 support on the RZ/V2H EVK board, CN3 supports host only operation and CN2 supports host/function operation. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250515183104.330964-3-prabhakar.mahadev-lad.rj@bp.renesas.com Link: https://lore.kernel.org/20250613152216.201957-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
generated by cgit (git 2.34.1) at 2025-09-22 14:15:51 +0000