summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-10-30arm64: dts: ti: k3-j722s-evm: explicitly use PLL1_HSDIV6 audio refclkMichael Walle
The parent of the audio_refclk0/1 is about to change to a sane default value. Thus, move the (soon to be) non-default value into the board device tree. Signed-off-by: Michael Walle <mwalle@kernel.org> Link: https://patch.msgid.link/20251017102228.530517-1-mwalle@kernel.org Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-10-30x86/microcode: Mark early_parse_cmdline() as __initYu Peng
Fix section mismatch warning reported by modpost: .text:early_parse_cmdline() -> .init.data:boot_command_line The function early_parse_cmdline() is only called during init and accesses init data, so mark it __init to match its usage. [ bp: This happens only when the toolchain fails to inline the function and I haven't been able to reproduce it with any toolchain I'm using. Patch is obviously correct regardless. ] Signed-off-by: Yu Peng <pengyu@kylinos.cn> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/all/20251030123757.1410904-1-pengyu@kylinos.cn
2025-10-30x86/microcode/AMD: Select which microcode patch to loadBorislav Petkov (AMD)
All microcode patches up to the proper BIOS Entrysign fix are loaded only after the sha256 signature carried in the driver has been verified. Microcode patches after the Entrysign fix has been applied, do not need that signature verification anymore. In order to not abandon machines which haven't received the BIOS update yet, add the capability to select which microcode patch to load. The corresponding microcode container supplied through firmware-linux has been modified to carry two patches per CPU type (family/model/stepping) so that the proper one gets selected. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Waiman Long <longman@redhat.com> Link: https://patch.msgid.link/20251027133818.4363-1-bp@kernel.org
2025-10-30x86/cpu: Add/fix core comments for {Panther,Nova} LakeTony Luck
The E-core in Panther Lake is Darkmont, not Crestmont. Nova Lake is built from Coyote Cove (P-core) and Arctic Wolf (E-core). Fixes: 43bb700cff6b ("x86/cpu: Update Intel Family comments") Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://patch.msgid.link/20251028172948.6721-1-tony.luck@intel.com
2025-10-30x86/CPU/AMD: Extend Zen6 model rangeBorislav Petkov (AMD)
Add some more Zen6 models. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://patch.msgid.link/20251029123056.19987-1-bp@kernel.org
2025-10-30ARM: dts: sti: remove useless cells fieldsRaphael Gallais-Pou
tvout node do not need the cells fields. Remove them. Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Acked-by: Patrice Chotard <patrice.chotard@foss.st.com> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20250717-sti-rework-v1-4-46d516fb1ebb@gmail.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2025-10-30ARM: dts: sti: extract display subsystem out of socRaphael Gallais-Pou
The display subsystem represent how IPs are interacting together and have nothing to do within the SoC node. Extract it from the SoC node and let IPs nodes in the Soc node. Several nodes did not use conventional name: * sti-display-subsystem -> display-subsystem * sti-controller -> display-controller * sti-tvout -> encoder * sti-hda -> analog * sti-hqvdp -> plane Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Acked-by: Patrice Chotard <patrice.chotard@foss.st.com> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Link: https://patch.msgid.link/20250717-sti-rework-v1-3-46d516fb1ebb@gmail.com Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
2025-10-30unwind_user/x86: Fix arch=um buildPeter Zijlstra
Add CONFIG_HAVE_UNWIND_USER_FP guards to make sure this code doesn't break arch=um builds. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Closes: https://lore.kernel.org/oe-kbuild-all/202510291919.FFGyU7nq-lkp@intel.com/
2025-10-29lib/crypto: arm/blake2b: Migrate optimized code into libraryEric Biggers
Migrate the arm-optimized BLAKE2b code from arch/arm/crypto/ to lib/crypto/arm/. This makes the BLAKE2b library able to use it, and it also simplifies the code because it's easier to integrate with the library than crypto_shash. This temporarily makes the arm-optimized BLAKE2b code unavailable via crypto_shash. A later commit reimplements the blake2b-* crypto_shash algorithms on top of the BLAKE2b library API, making it available again. Note that as per the lib/crypto/ convention, the optimized code is now enabled by default. So, this also fixes the longstanding issue where the optimized BLAKE2b code was not enabled by default. To see the diff from arch/arm/crypto/blake2b-neon-glue.c to lib/crypto/arm/blake2b.h, view this commit with 'git show -M10'. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20251018043106.375964-8-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-10-29ARM: Select ARCH_USES_CFI_GENERIC_LLVM_PASSNathan Chancellor
Prior to clang 22.0.0 [1], ARM did not have an architecture specific kCFI bundle lowering in the backend, which may cause issues. Select CONFIG_ARCH_USES_CFI_GENERIC_LLVM_PASS to enable use of __nocfi_generic. Link: https://github.com/llvm/llvm-project/commit/d130f402642fba3d065aacb506cb061c899558de [1] Link: https://github.com/ClangBuiltLinux/linux/issues/2124 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20251025-idpf-fix-arm-kcfi-build-error-v1-2-ec57221153ae@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-10-29compiler_types: Introduce __nocfi_genericNathan Chancellor
There are two different ways that LLVM can expand kCFI operand bundles in LLVM IR: generically in the middle end or using an architecture specific sequence when lowering LLVM IR to machine code in the backend. The generic pass allows any architecture to take advantage of kCFI but the expansion of these bundles in the middle end can mess with optimizations that may turn indirect calls into direct calls when the call target is known at compile time, such as after inlining. Add __nocfi_generic, dependent on an architecture selecting CONFIG_ARCH_USES_CFI_GENERIC_LLVM_PASS, to disable kCFI bundle generation in functions where only the generic kCFI pass may cause problems. Link: https://github.com/ClangBuiltLinux/linux/issues/2124 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20251025-idpf-fix-arm-kcfi-build-error-v1-1-ec57221153ae@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-10-29arm64: dts: qcom: Add display support for QCS615 RIDE boardLi Liu
Add display MDSS and DSI configuration for QCS615 RIDE board. QCS615 has a DP port, and DP support will be added in a later patch. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Li Liu <li.liu@oss.qualcomm.com> Signed-off-by: Fange Zhang <fange.zhang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250903-add-display-support-for-qcs615-platform-v8-2-7971c05d1262@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-29arm64: dts: qcom: Add display support for QCS615Li Liu
Add display MDSS and DSI configuration for QCS615 platform. QCS615 has a DP port, and DP support will be added in a later patch. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Li Liu <li.liu@oss.qualcomm.com> Signed-off-by: Fange Zhang <fange.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250903-add-display-support-for-qcs615-platform-v8-1-7971c05d1262@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-29arm64: dts: qcom: sm8550: Limit max SD HS mode frequency by defaultSarthak Garg
Due to an implementation detail in this SoC, additional passive electrical components are required to achieve the maximum rated speed of the SD controller when paired with a High-Speed SD Card. Without them, the clock frequency must be limited to 37.5 MHz for link stability. Because the reference design does not contain these components, most (derivative) boards do not have them either. To accommodate for that, apply the frequency limit by default and delegate lifting it to the odd boards that do contain the necessary onboard hardware. Signed-off-by: Sarthak Garg <quic_sartgarg@quicinc.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250908104122.2062653-5-quic_sartgarg@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-29arm64: dts: qcom: qcs615-ride: Update 'model' string for qcs615 rideXin Liu
Update the 'model' property in the QCS615-ride device tree to include the public board name "IQ-615 Beta EVK". This ensures consistency with official documentation and release notes. Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251029023137.381386-1-xin.liu@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-29s390/mm: Fix memory leak in add_marker() when kvrealloc() failsMiaoqian Lin
The function has a memory leak when kvrealloc() fails. The function directly assigns NULL to the markers pointer, losing the reference to the previously allocated memory. This causes kvfree() in pt_dump_init() to free NULL instead of the leaked memory. Fix by: 1. Using kvrealloc() uniformly for all allocations 2. Using a temporary variable to preserve the original pointer until allocation succeeds 3. Removing the error path that sets markers_cnt=0 to keep consistency between markers and markers_cnt Found via static analysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-10-29x86/dumpstack: Prevent KASAN false positive warnings in __show_regs()Tengda Wu
When triggering a stack dump via sysrq (echo t > /proc/sysrq-trigger), KASAN may report false-positive out-of-bounds access: BUG: KASAN: out-of-bounds in __show_regs+0x4b/0x340 Call Trace: dump_stack_lvl print_address_description.constprop.0 print_report __show_regs show_trace_log_lvl sched_show_task show_state_filter sysrq_handle_showstate __handle_sysrq write_sysrq_trigger proc_reg_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe The issue occurs as follows: Task A (walk other tasks' stacks) Task B (running) 1. echo t > /proc/sysrq-trigger show_trace_log_lvl regs = unwind_get_entry_regs() show_regs_if_on_stack(regs) 2. The stack value pointed by `regs` keeps changing, and so are the tags in its KASAN shadow region. __show_regs(regs) regs->ax, regs->bx, ... 3. hit KASAN redzones, OOB When task A walks task B's stack without suspending it, the continuous changes in task B's stack (and corresponding KASAN shadow tags) may cause task A to hit KASAN redzones when accessing obsolete values on the stack, resulting in false positive reports. Simply stopping the task before unwinding is not a viable fix, as it would alter the state intended to inspect. This is especially true for diagnosing misbehaving tasks (e.g., in a hard lockup), where stopping might fail or hide the root cause by changing the call stack. Therefore, fix this by disabling KASAN checks during asynchronous stack unwinding, which is identified when the unwinding task does not match the current task (task != current). [ bp: Align arguments on function's opening brace. ] Fixes: 3b3fa11bc700 ("x86/dumpstack: Print any pt_regs found on the stack") Signed-off-by: Tengda Wu <wutengda@huaweicloud.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com> Acked-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://patch.msgid.link/all/20251023090632.269121-1-wutengda@huaweicloud.com
2025-10-29perf/x86/intel/uncore: Add uncore PMU support for Wildcat Lakedongsheng
WildcatLake (WCL) is a variant of PantherLake (PTL) and shares the same uncore PMU features with PTL. Therefore, directly reuse Pantherlake's uncore PMU enabling code for WildcatLake. Signed-off-by: dongsheng <dongsheng.x.zhang@intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20250908061639.938105-2-dapeng1.mi@linux.intel.com
2025-10-29perf/x86/intel: Add PMU support for WildcatLakeDapeng Mi
WildcatLake is a variant of PantherLake and shares same PMU features, so directly reuse Pantherlake's code to enable PMU features for WildcatLake. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Zide Chen <zide.chen@intel.com> Link: https://patch.msgid.link/20250908061639.938105-1-dapeng1.mi@linux.intel.com
2025-10-29unwind_user/x86: Teach FP unwind about start of functionPeter Zijlstra
When userspace is interrupted at the start of a function, before we get a chance to complete the frame, unwind will miss one caller. X86 has a uprobe specific fixup for this, add bits to the generic unwinder to support this. Suggested-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251024145156.GM4068168@noisy.programming.kicks-ass.net
2025-10-29unwind_user/x86: Enable frame pointer unwinding on x86Josh Poimboeuf
Use ARCH_INIT_USER_FP_FRAME to describe how frame pointers are unwound on x86, and enable CONFIG_HAVE_UNWIND_USER_FP accordingly so the unwind_user interfaces can be used. Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20250827193828.347397433@kernel.org
2025-10-29perf/x86/intel/cstate: Add Pantherlake supportZhang Rui
Like Lunarlake, Pantherlake supports CC1/CC6/CC7 and PC2/PC6/PC10. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251023223754.1743928-4-zide.chen@intel.com
2025-10-29perf/x86/intel/cstate: Remove PC3 support from LunarLakeZhang Rui
LunarLake doesn't support Package C3. Remove the PC3 residency counter support from LunarLake. Fixes: 26579860fbd5 ("perf/x86/intel/cstate: Add Lunarlake support") Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251023223754.1743928-3-zide.chen@intel.com
2025-10-29perf/x86/intel/cstate: Add Clearwater Forest supportZide Chen
Clearwater Forest is based on the Darkmont Atom microarchitecture. >From the perspective of C-state residency profiling, it supports the same residency counters as Sierra Forest: CC1/CC6, PC2/PC6, and MC6. Please note that the C1E residency counter can only be read via PMT, not MSR. Therefore, tools relying on the perf_event framework cannot access the C1E residency. Signed-off-by: Zhenyu Wang <zhenyuw.linux@gmail.com> Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251023223754.1743928-2-zide.chen@intel.com
2025-10-29perf/x86/intel: Fix KASAN global-out-of-bounds warningDapeng Mi
When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen. ================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 Call Trace: kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80 The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big) So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue. Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions") Reported-by: Xudong Hao <xudong.hao@intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Zide Chen <zide.chen@intel.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251028064214.1451968-1-dapeng1.mi@linux.intel.com
2025-10-29x86: Use physical address for DMA mappingLeon Romanovsky
Perform mechanical conversion from DMA .map_page to .map_phys. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-12-3bbfe3a25cdf@kernel.org
2025-10-29sparc: Use physical address DMA mappingLeon Romanovsky
Convert sparc architecture DMA code to use .map_phys callback. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-11-3bbfe3a25cdf@kernel.org
2025-10-29powerpc: Convert to physical address DMA mappingLeon Romanovsky
Adapt PowerPC DMA to use physical addresses in order to prepare code to removal .map_page and .unmap_page. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-10-3bbfe3a25cdf@kernel.org
2025-10-29MIPS/jazzdma: Provide physical address directlyLeon Romanovsky
MIPS jazz uses physical addresses for mapping pages, so convert it to get them directly from DMA mapping routine. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-8-3bbfe3a25cdf@kernel.org
2025-10-29alpha: Convert mapping routine to rely on physical addressLeon Romanovsky
Alpha doesn't need struct *page and can perform mapping based on physical addresses. So convert it to implement new .map_phys callback. As part of this change, remove useless BUG_ON() as DMA mapping layer ensures that right direction is provided. Tested-by: Magnus Lindholm <linmag7@gmail.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-7-3bbfe3a25cdf@kernel.org
2025-10-29ARM: dma-mapping: Switch to physical address mapping callbacksLeon Romanovsky
Combine resource and page mappings routines to one function, which handles both these flows at the same manner. This conversion allows us to remove .map_resource/.unmap_resource callbacks completely. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-4-3bbfe3a25cdf@kernel.org
2025-10-29ARM: dma-mapping: Reduce struct page exposure in arch_sync_dma*()Leon Romanovsky
As a preparation to changing from .map_page to use .map_phys DMA callbacks, convert arch_sync_dma*() functions to use physical addresses instead of struct page. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20251015-remove-map-page-v5-3-3bbfe3a25cdf@kernel.org
2025-10-29Merge branch 'linus/master' into sched/core, to resolve conflictPeter Zijlstra
Conflicts: kernel/sched/ext.c Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-10-29arm64: dts: ti: k3-am62: Add RNG nodeShiva Tripathi
Add EIP76 Random Number Generator (RNG) node within crypto engine for AM62 and AM62A SoCs. The RNG hardware is integrated in crypto subsystem at address 0x40910000. Mark the RNG node with status "reserved" as it is intended for use by OP-TEE for secure random number generation. If required, this hardware can also be used through Linux kernel by enabling this node. Signed-off-by: Shiva Tripathi <s-tripathi1@ti.com> Link: https://patch.msgid.link/20250926100229.923547-1-s-tripathi1@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2025-10-28arm64: dts: qcom: ipq5424: Add NSS clock controller nodeLuo Jie
NSS clock controller provides the clocks and resets to the networking hardware blocks on the IPQ5424, such as PPE (Packet Process Engine) and UNIPHY (PCS) blocks. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Luo Jie <quic_luoj@quicinc.com> Link: https://lore.kernel.org/r/20251014-qcom_ipq5424_nsscc-v7-9-081f4956be02@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-10-28x86/build: Disable SSE4aPeter Zijlstra
Leyvi Rose reported that his X86_NATIVE_CPU=y build is failing because our instruction decoder doesn't support SSE4a and the AMDGPU code seems to be generating those with his compiler of choice (CLANG+LTO). Now, our normal build flags disable SSE MMX SSE2 3DNOW AVX, but then CC_FLAGS_FPU re-enable SSE SSE2. Since nothing mentions SSE3 or SSE4, I'm assuming that -msse (or its negative) control all SSE variants -- but why then explicitly enumerate SSE2 ? Anyway, until the instruction decoder gets fixed, explicitly disallow SSE4a (an AMD specific SSE4 extension). Fixes: ea1dcca1de12 ("x86/kbuild/64: Add the CONFIG_X86_NATIVE_CPU option to locally optimize the kernel with '-march=native'") Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Arisu Tachibana <arisu.tachibana@miraclelinux.com> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: <stable@kernel.org>
2025-10-28x86/fpu: Ensure XFD state on signal deliveryChang S. Bae
Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenario involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if there is a dynamic feature. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. [ dhansen: minor changelog munging ] Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Tested-by: Chao Gao <chao.gao@intel.com> Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] Cc:stable@vger.kernel.org Link: https://patch.msgid.link/20250610001700.4097-1-chang.seok.bae%40intel.com
2025-10-29arm64: dts: allwinner: a523: Add SPDIF TX pin on PB and PI pinsChen-Yu Tsai
The SPDIF TX (called OWA OUT in the datasheet) is available on three pins. Of those, the PH pin is unlikely to be used since it conflicts with the first Ethernet controller. The Radxa Cubie A5E exposes SPDIF TX through the PI pin group on the 40-pin GPIO header. The Orange Pi 4A exposes SPDIF TX through both the PB and PI pin groups on the 40-pin GPIO header. The PB pin alternatively would be used for I2S0 though. Add pinmux settings for both options so potential users can directly reference either one. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251027125655.793277-10-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-10-29arm64: dts: allwinner: a523: Add I2S2 pins on PI pin groupChen-Yu Tsai
The Radxa Cubie A5E exposes I2S2 through the PI pin group on the 40-pin GPIO header. Add a pinmux setting for it so potential users can directly reference it. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251027125655.793277-9-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-10-29arm64: dts: allwinner: a523: Add device nodes for I2S controllersChen-Yu Tsai
The A523 family of SoCs have four I2S controllers capable of both playback and capture. The user manual also implies that I2S2 also outputs to the eDP interface controller. Add device nodes for all of them. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251027125655.793277-8-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-10-29arm64: dts: allwinner: a523: Add device node for SPDIF blockChen-Yu Tsai
The A523 has a SPDIF interface that is capable of both playback and capture. Add a node for it. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251027125655.793277-7-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-10-29arm64: dts: allwinner: a523: Add DMA controller device nodesChen-Yu Tsai
The A523 has two DMA controllers. Add device nodes for both. Also hook up DMA for existing devices. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251027125655.793277-6-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-10-29arm64: dts: allwinner: h616: add NAND controllerRichard Genoud
The H616 has a NAND controller quite similar to the A10/A23 ones, but with some register differences, more clocks (for ECC and MBUS), more ECC strengths, so this requires a new compatible string. Add the NAND controller node and pins in the device tree. Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Link: https://patch.msgid.link/20251028073534.526992-17-richard.genoud@bootlin.com [wens@kernel.org: Fixed alignment of clocks in nand-controller node] Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2025-10-28x86/CPU/AMD: Add RDSEED fix for Zen5Gregory Price
There's an issue with RDSEED's 16-bit and 32-bit register output variants on Zen5 which return a random value of 0 "at a rate inconsistent with randomness while incorrectly signaling success (CF=1)". Search the web for AMD-SB-7055 for more detail. Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ] Cc: stable@vger.kernel.org Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20251018024010.4112396-1-gourry@gourry.net
2025-10-28um: Avoid circular dependency on asm-offsets in pgtable.hThomas Weißschuh
Recent changes have added an include of as-layout.h to pgtable.h. However this introduces a circular dependency during asm-offsets generation as as-layout.h depends on asm-offsets and pgtable.h is an input for asm-offsets. Building from a clean state results in the following error: CC arch/um/kernel/asm-offsets.s In file included from arch/um/include/asm/pgtable.h:48, from include/linux/pgtable.h:6, from include/linux/mm.h:31, from include/linux/pid_namespace.h:7, from include/linux/ptrace.h:10, from include/linux/audit.h:13, from arch/um/kernel/asm-offsets.c:8: arch/um/include/shared/as-layout.h:9:10: fatal error: generated/asm-offsets.h: No such file or directory 9 | #include <generated/asm-offsets.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[4]: *** [scripts/Makefile.build:182: arch/um/kernel/asm-offsets.s] Error 1 As the inclusion of as-layout.h in pgtable.h is not yet needed while asm-offsets are generated, break the dependency here. Fixes: a7f7dbae94a5 ("um: Remove file-based iomem emulation support") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20251028-uml-offsets-circular-v1-1-601c363cfaaa@weissschuh.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-10-28riscv: dts: thead: Add PWM fan and thermal controlMichal Wilczynski
Add Device Tree nodes to enable a PWM controlled fan and it's associated thermal management for the Lichee Pi 4A board. This enables temperature-controlled active cooling for the Lichee Pi 4A board based on SoC temperature. Reviewed-by: Drew Fustini <fustini@kernel.org> Tested-by: Drew Fustini <fustini@kernel.org> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-28riscv: dts: thead: Add PWM controller nodeMichal Wilczynski
Add the Device Tree node for the T-HEAD TH1520 SoC's PWM controller. Reviewed-by: Drew Fustini <fustini@kernel.org> Tested-by: Drew Fustini <fustini@kernel.org> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Drew Fustini <fustini@kernel.org>
2025-10-28arm64: dts: imx8mp-kontron: Fix USB OTG role switchingFrieder Schrempf
The VBUS supply regulator is currently assigned to the PHY node. This causes the VBUS to be always on, even when the controller needs to be switched to peripheral mode. Fix the OTG role switching by adding a connector node and moving the VBUS supply regulator to that node. This way the VBUS gets correctly switched according to the current role. Fixes: 946ab10e3f40 ("arm64: dts: Add support for Kontron OSM-S i.MX8MP SoM and BL carrier board") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-28arm64: dts: layerscape: add dma-coherent for usb nodeFrank Li
Add SOC special compatible string, remove fallback snps,dwc3 to let flatten dwc3-layerscape driver to be probed and enable dma-coherence for usb node since commit add layerscape dwc3 support, which set correct gsbustcfg0 value. Add iommus property to run at old uboot, which use fixup add iommus by check compatible string snsp,dwc3 compatible string. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-10-28arm64: dts: renesas: r8a77961: Add GX6250 GPU nodeMarek Vasut
Describe Imagination Technologies PowerVR Rogue GX6250 BNVC 4.45.2.58 present in Renesas R-Car R8A77961 M3-W+ SoC. Acked-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251022033847.471106-3-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-28 09:55:53 +0000