summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-01-08KVM: VMX: Fix comment of handle_vmx_instruction()Gao Shiyuan
Fix a goof in handle_vmx_instruction()'s comment where it references the non-existent nested_vmx_setup(); the function that overwrites the exit handlers is nested_vmx_hardware_setup(). Note, this isn't a case of a stale comment, e.g. due to the function being renamed. The comment has always been wrong. Fixes: e4027cfafd78 ("KVM: nVMX: Set callbacks for nested functions during hardware setup") Signed-off-by: Gao Shiyuan <gaoshiyuan@baidu.com> Link: https://lore.kernel.org/r/20250103153814.73903-1-gaoshiyuan@baidu.com [sean: massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-01-08KVM: VMX: Reinstate __exit attribute for vmx_exit()Costas Argyris
Tag vmx_exit() with __exit now that it's no longer used by vmx_init(). Commit a7b9020b06ec ("x86/l1tf: Handle EPT disabled state proper") dropped the "__exit" attribute from vmx_exit() because vmx_init() was changed to call vmx_exit(). However, commit e32b120071ea ("KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace") changed vmx_init() to call __vmx_exit() instead of the "full" vmx_exit(). This made it possible to mark vmx_exit() as "__exit" again, as it originally was, and enjoy the benefits that it provides (the function can be discarded from memory in situations where it cannot be called, like the module being built-in or module unloading being disabled in the kernel). Signed-off-by: Costas Argyris <costas.argyris@amd.com> Link: https://lore.kernel.org/r/20250102154050.2403-1-costas.argyris@amd.com [sean: massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-01-08KVM: SVM: Use str_enabled_disabled() helper in sev_hardware_setup()Thorsten Blum
Remove hard-coded strings by using the str_enabled_disabled() helper function. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Pavan Kumar Paluri <papaluri@amd.com> Reviewed-by: Nikunj A Dadhania <nikunj@amd.com> Link: https://lore.kernel.org/r/20241227094450.674104-2-thorsten.blum@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-01-08KVM: x86: Avoid double RDPKRU when loading host/guest PKRUSean Christopherson
Use the raw wrpkru() helper when loading the guest/host's PKRU on switch to/from guest context, as the write_pkru() wrapper incurs an unnecessary rdpkru(). In both paths, KVM is guaranteed to have performed RDPKRU since the last possible write, i.e. KVM has a fresh cache of the current value in hardware. This effectively restores KVM's behavior to that of KVM prior to commit c806e88734b9 ("x86/pkeys: Provide *pkru() helpers"), which renamed the raw helper from __write_pkru() => wrpkru(), and turned __write_pkru() into a wrapper. Commit 577ff465f5a6 ("x86/fpu: Only write PKRU if it is different from current") then added the extra RDPKRU to avoid an unnecessary WRPKRU, but completely missed that KVM already optimized away pointless writes. Reported-by: Adrian Hunter <adrian.hunter@intel.com> Fixes: 577ff465f5a6 ("x86/fpu: Only write PKRU if it is different from current") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20241221011647.3747448-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-01-08KVM: x86: Use LVT_TIMER instead of an open coded literalLiam Ni
Use LVT_TIMER instead of the literal '0' to clean up the apic_lvt_mask lookup when emulating handling writes to APIC_LVTT. No functional change intended. Signed-off-by: Liam Ni <zhiguangni01@gmail.com> [sean: manually regenerate patch (whitespace damaged), massage changelog] Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-01-08x86/tsc: Init the TSC for Secure TSC guestsNikunj A Dadhania
Use the GUEST_TSC_FREQ MSR to discover the TSC frequency instead of relying on kvm-clock based frequency calibration. Override both CPU and TSC frequency calibration callbacks with securetsc_get_tsc_khz(). Since the difference between CPU base and TSC frequency does not apply in this case, the same callback is being used. [ bp: Carve out from https://lore.kernel.org/r/20250106124633.1418972-11-nikunj@amd.com ] Signed-off-by: Nikunj A Dadhania <nikunj@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20250106124633.1418972-11-nikunj@amd.com
2025-01-08riscv: use local label names instead of global ones in assemblyClément Léger
Local labels should be prefix by '.L' or they'll be exported in the symbol table. Additionally, this messes up the backtrace by displaying an incorrect symbol: ... [ 12.751810] [<ffffffff80441628>] _copy_from_user+0x28/0xc2 [ 12.752035] [<ffffffff800152ca>] handle_misaligned_load+0x1ca/0x2fc [ 12.752310] [<ffffffff80a033e8>] do_trap_load_misaligned+0x24/0xee [ 12.752596] [<ffffffff80a0dcae>] _new_vmalloc_restore_context_a0+0xc2/0xce After: ... [ 10.243916] [<ffffffff804415e4>] _copy_from_user+0x28/0xc2 [ 10.244026] [<ffffffff800152ca>] handle_misaligned_load+0x1ca/0x2fc [ 10.244150] [<ffffffff80a033a0>] do_trap_load_misaligned+0x24/0xee [ 10.244268] [<ffffffff80a0dc66>] handle_exception+0x146/0x152 Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: 503638e0babf3 ("riscv: Stop emitting preventive sfence.vma for new vmalloc mappings") Link: https://lore.kernel.org/r/20250103141814.508865-1-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08riscv: qspinlock: Fixup _Q_PENDING_LOOPS definitionGuo Ren
When CONFIG_RISCV_QUEUED_SPINLOCKS=y, the _Q_PENDING_LOOPS definition is missing. Add the _Q_PENDING_LOOPS definition for pure qspinlock usage. Fixes: ab83647fadae ("riscv: Add qspinlock support") Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20241215135252.201983-1-guoren@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08riscv: stacktrace: fix backtracing through exceptionsClément Léger
Prior to commit 5d5fc33ce58e ("riscv: Improve exception and system call latency"), backtrace through exception worked since ra was filled with ret_from_exception symbol address and the stacktrace code checked 'pc' to be equal to that symbol. Now that handle_exception uses regular 'call' instructions, this isn't working anymore and backtrace stops at handle_exception(). Since there are multiple call site to C code in the exception handling path, rather than checking multiple potential return addresses, add a new symbol at the end of exception handling and check pc to be in that range. Fixes: 5d5fc33ce58e ("riscv: Improve exception and system call latency") Signed-off-by: Clément Léger <cleger@rivosinc.com> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20241209155714.1239665-1-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08riscv: mm: Fix the out of bound issue of vmemmap addressXu Lu
In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base. Fixes: a11dd49dcb93 ("riscv: Sparse-Memory/vmemmap out-of-bounds fix") Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/r/20241209122617.53341-1-luxu.kernel@bytedance.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08riscv: kprobes: Fix incorrect address calculationNam Cao
p->ainsn.api.insn is a pointer to u32, therefore arithmetic operations are multiplied by four. This is clearly undesirable for this case. Cast it to (void *) first before any calculation. Below is a sample before/after. The dumped memory is two kprobe slots, the first slot has - c.addiw a0, 0x1c (0x7125) - ebreak (0x00100073) and the second slot has: - c.addiw a0, -4 (0x7135) - ebreak (0x00100073) Before this patch: (gdb) x/16xh 0xff20000000135000 0xff20000000135000: 0x7125 0x0000 0x0000 0x0000 0x7135 0x0010 0x0000 0x0000 0xff20000000135010: 0x0073 0x0010 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 After this patch: (gdb) x/16xh 0xff20000000125000 0xff20000000125000: 0x7125 0x0073 0x0010 0x0000 0x7135 0x0073 0x0010 0x0000 0xff20000000125010: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 Fixes: b1756750a397 ("riscv: kprobes: Use patch_text_nosync() for insn slots") Signed-off-by: Nam Cao <namcao@linutronix.de> Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20241119111056.2554419-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08riscv: Fix sleeping in invalid context in die()Nam Cao
die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlock_t which can sleep with PREEMPT_RT enabled. That causes the following warning: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex preempt_count: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dump_backtrace+0x1c/0x24 show_stack+0x2c/0x38 dump_stack_lvl+0x5a/0x72 dump_stack+0x14/0x1c __might_resched+0x130/0x13a rt_spin_lock+0x2a/0x5c die+0x24/0x112 do_trap_insn_illegal+0xa0/0xea _new_vmalloc_restore_context_a0+0xcc/0xd8 Oops - illegal instruction [#1] Switch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT enabled. Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code") Signed-off-by: Nam Cao <namcao@linutronix.de> Cc: stable@vger.kernel.org Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20241118091333.1185288-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08riscv: module: remove relocation_head rel_entry member allocationClément Léger
relocation_head's list_head member, rel_entry, doesn't need to be allocated, its storage can just be part of the allocated relocation_head. Remove the pointer which allows to get rid of the allocation as well as an existing memory leak found by Kai Zhang using kmemleak. Fixes: 8fd6c5142395 ("riscv: Add remaining module relocations") Reported-by: Kai Zhang <zhangkai@iscas.ac.cn> Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20241128081636.3620468-1-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-01-08treewide: Introduce kthread_run_worker[_on_cpu]()Frederic Weisbecker
kthread_create() creates a kthread without running it yet. kthread_run() creates a kthread and runs it. On the other hand, kthread_create_worker() creates a kthread worker and runs it. This difference in behaviours is confusing. Also there is no way to create a kthread worker and affine it using kthread_bind_mask() or kthread_affine_preferred() before starting it. Consolidate the behaviours and introduce kthread_run_worker[_on_cpu]() that behaves just like kthread_run(). kthread_create_worker[_on_cpu]() will now only create a kthread worker without starting it. Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
2025-01-08sched,arm64: Handle CPU isolation on last resort fallback rq selectionFrederic Weisbecker
When a kthread or any other task has an affinity mask that is fully offline or unallowed, the scheduler reaffines the task to all possible CPUs as a last resort. This default decision doesn't mix up very well with nohz_full CPUs that are part of the possible cpumask but don't want to be disturbed by unbound kthreads or even detached pinned user tasks. Make the fallback affinity setting aware of nohz_full. Suggested-by: Michal Hocko <mhocko@suse.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-01-08arm64: Exclude nohz_full CPUs from 32bits el0 supportFrederic Weisbecker
Nohz full CPUs are not a desirable fallback target to run 32bits el0 applications. If present, prefer a set of housekeeping CPUs that can do the job instead. Otherwise just don't support el0 32 bits. Should the need arise, appropriate support can be introduced in the future. Suggested-by: Will Deacon <will@kernel.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-01-08m68k: vga: Fix I/O definesThomas Zimmermann
Including m68k's <asm/raw_io.h> in vga.h on nommu platforms results in conflicting defines with io_no.h for various I/O macros from the __raw_read and __raw_write families. An example error is In file included from arch/m68k/include/asm/vga.h:12, from include/video/vga.h:22, from include/linux/vgaarb.h:34, from drivers/video/aperture.c:12: >> arch/m68k/include/asm/raw_io.h:39: warning: "__raw_readb" redefined 39 | #define __raw_readb in_8 | In file included from arch/m68k/include/asm/io.h:6, from include/linux/io.h:13, from include/linux/irq.h:20, from include/asm-generic/hardirq.h:17, from ./arch/m68k/include/generated/asm/hardirq.h:1, from include/linux/hardirq.h:11, from include/linux/interrupt.h:11, from include/linux/trace_recursion.h:5, from include/linux/ftrace.h:10, from include/linux/kprobes.h:28, from include/linux/kgdb.h:19, from include/linux/fb.h:6, from drivers/video/aperture.c:5: arch/m68k/include/asm/io_no.h:16: note: this is the location of the previous definition 16 | #define __raw_readb(addr) \ | Include <asm/io.h>, which avoids raw_io.h on nommu platforms. Also change the defined values of some of the read/write symbols in vga.h to __raw_read/__raw_write as the raw_in/raw_out symbols are not generally available. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501071629.DNEswlm8-lkp@intel.com/ Fixes: 5c3f968712ce ("m68k/video: Create <asm/vga.h>") Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v3.5+ Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/20250107095912.130530-1-tzimmermann@suse.de Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2025-01-08m68k: atari: Use str_on_off() helper in atari_nvram_proc_read()Thorsten Blum
Remove hard-coded strings by using the str_on_off() helper function. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/20241206115634.47332-2-thorsten.blum@linux.dev Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2025-01-08arm64: defconfig: Enable TI K3 M4 remoteproc driverHari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build the M4 remote proc driver as a module for these platforms. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Wadim Egorov <w.egorov@phytec.de> Link: https://lore.kernel.org/r/20240802152109.137243-10-afd@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-am62a-wakeup: Configure ti-sysc for wkup_uart0Vibhore Vardhan
Similar to the TI K3-AM62x SoC commit ce27f7f9e328c8582a169f97f1466976561f1 ("arm64: dts: ti: k3-am62-wakeup: Configure ti-sysc for wkup_uart0"), The devices in the wkup domain are capable of waking up the system from suspend. We can configure the wkup domain devices in a generic way using the ti-sysc interconnect target module driver like we have done with the earlier TI SoCs. As ti-sysc manages the SYSCONFIG related registers independent of the child hardware device, the wake-up configuration is also set even if wkup_uart0 is reserved by sysfw. The wkup_uart0 device has interconnect target module register mapping like dra7 wkup uart. There is a 1 MB interconnect target range with one uart IP block in the target module. The power domain and clock affects the whole interconnect target module. Note we change the functional clock name to follow the ti-sysc binding and use "fck" instead of "fclk". Also note that we need to disable the target module reset as noted by Markus. Otherwise the sysfw using wkup_uart0 can get confused on some devices leading to boot time issues such as mbox timeouts. Signed-off-by: Vibhore Vardhan <vibhore@ti.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> [d-gole@ti.com: Reworded the entire commit message] Signed-off-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241231-am62a-dt-ti-sysc-wkup-v1-1-a9b0d18a2649@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-j722s-evm: Enable PMICUdit Kumar
Add support for TPS6522x PMIC family on wakeup I2C0 bus. This device provides regulators (bucks and LDOs), along with GPIOs, and monitors SOC's MCU error signal. Signed-off-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20250102103814.102499-1-u-kumar1@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-am69-sk: Add USB SuperSpeed supportDasnavis Sabiya
AM69 SK board has two stacked USB3 connectors: 1. USB3 (Stacked TypeA + TypeC) 2. USB3 TypeA Hub interfaced through TUSB8041. The board uses SERDES0 Lane 3 for USB3 IP. So update the SerDes lane info for PCIe and USB. Add the pin mux data and enable USB 3.0 support with its respective SERDES settings. Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com> Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20250108-am69sk-dt-usb-v3-1-bb4981534754@redhat.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-am625-beagleplay: Fix DP83TD510E reset timeFrancesco Valla
The reset deassert time for the DP83TD510E is incorrectly set to 60000us, while the datasheet states that the minimum time required after an hard reset is 30us (while 60ms is the time required for the Power-On Reset after supply stabilization). The error probably arose from the two timings being indicated by the same symbol (T2). Lower the required time to 35us, aligning it to the value required for the PHY to complete the reset AND to be able to accept the RMII master clock. This saves ~60ms on boot if the MDIO driver is built-in. Signed-off-by: Francesco Valla <francesco@valla.it> Link: https://lore.kernel.org/r/20250105162630.243899-1-francesco@valla.it Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-am642-hummingboard-t: Convert overlay to board dtsJosua Mayer
SolidRun HummingBoard-T has two options for M.2 connector, supporting either PCI-E or USB-3.1 Gen 1 - depending on configuration of a mux on the serdes lane. The required configurations in device-tree were modeled as overlays. The USB-3.1 overlay uses /delete-property/ to unset a boolean property on the usb controller limiting it to USB-2.0 by default. Overlays can not delete a property from the base dtb, therefore this overlay is at this time useless. Convert both overlays into full dts by including the base board dts. While the pcie overlay was functional, both are converted for a consistent user experience when selecting between the two mutually exclusive configurations. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/linux-devicetree/CAMuHMdXTgpTnJ9U7egC2XjFXXNZ5uiY1O+WxNd6LPJW5Rs5KTw@mail.gmail.com Fixes: bbef42084cc1 ("arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3") Signed-off-by: Josua Mayer <josua@solid-run.com> Link: https://lore.kernel.org/r/20250101-am64-hb-fix-overlay-v2-1-78143f5da28c@solid-run.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-am69-sk: Add overlay for PCIE0 Endpoint ModeSiddharth Vadapalli
Add overlay to enable the PCIE0 instance of PCIe on AM69-SK in Endpoint mode of operation. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20241205105041.749576-5-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-am68-sk-base-board: Add overlay for PCIE1 Endpoint ModeSiddharth Vadapalli
Add overlay to enable the PCIE1 instance of PCIe on AM68-SK-Base-Board in Endpoint mode of operation. PCIE1 on AM68-SK-Base-Board supports x2 Lane operation unlike its counterpart on J721S2-EVM which supports x1 Lane. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20241205105041.749576-4-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: k3-j721e-evm: Add overlay for PCIE1 Endpoint ModeSiddharth Vadapalli
Add overlay to enable the PCIE1 instance of PCIe on J721E-EVM in Endpoint mode of operation. Additionally, in order to support both PCIE0 and PCIE1 in Endpoint Mode of operation, enable applying device-tree overlays on "k3-j721e-evm-pcie0-ep.dtb", thereby allowing the overlay for PCIE1 in Endpoint mode to be applied on the aforementioned DTB. Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20241205105041.749576-3-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: dts: ti: Makefile: Fix typo "k3-j7200-evm-pcie1-ep.dtbo"Siddharth Vadapalli
The list of "dtbs" should contain the resultant "dtb" formed by applying the "dtbo" overlay on the base "dtb", rather than the "dtbo" itself. Hence, change "k3-j7200-evm-pcie1-ep.dtbo" to "k3-j7200-evm-pcie1-ep.dtb" in the list of "dtbs". Fixes: f43ec89bbc83 ("arm64: dts: ti: k3-j7200-evm: Add overlay for PCIE1 Endpoint Mode") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://lore.kernel.org/r/20241205105041.749576-2-s-vadapalli@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2025-01-08arm64: rsi: Add automatic arm-cca-guest module loadingJeremy Linton
The TSM module provides guest identification and attestation when a guest runs in CCA realm mode. By creating a dummy platform device, let's ensure the module is automatically loaded. The udev daemon loads the TSM module after it receives a device addition event. Once that happens, it can be used earlier in the boot process to decrypt the rootfs. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20241220181236.172060-2-jeremy.linton@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-01-08KVM: arm64: Allow control of dpISA extensions in ID_AA64ISAR3_EL1Mark Brown
ID_AA64ISAR3_EL1 is currently marked as unallocated in KVM but does have a number of bitfields defined in it. Expose FPRCVT and FAMINMAX, two simple instruction only extensions to guests. Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250107-arm64-2024-dpisa-v5-4-7578da51fc3d@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-01-08arm64/hwcap: Describe 2024 dpISA extensions to userspaceMark Brown
The 2024 dpISA introduces a number of architecture features all of which only add new instructions so only require the addition of hwcaps and ID register visibility. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250107-arm64-2024-dpisa-v5-3-7578da51fc3d@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-01-08arm64/sysreg: Update ID_AA64SMFR0_EL1 to DDI0601 2024-12Mark Brown
DDI0601 2024-12 introduces SME 2.2 as well as a few new optional features, update sysreg to reflect the changes in ID_AA64SMFR0_EL1 enumerating them. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250107-arm64-2024-dpisa-v5-2-7578da51fc3d@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-01-08arm64: Filter out SVE hwcaps when FEAT_SVE isn't implementedMarc Zyngier
The hwcaps code that exposes SVE features to userspace only considers ID_AA64ZFR0_EL1, while this is only valid when ID_AA64PFR0_EL1.SVE advertises that SVE is actually supported. The expectations are that when ID_AA64PFR0_EL1.SVE is 0, the ID_AA64ZFR0_EL1 register is also 0. So far, so good. Things become a bit more interesting if the HW implements SME. In this case, a few ID_AA64ZFR0_EL1 fields indicate *SME* features. And these fields overlap with their SVE interpretations. But the architecture says that the SME and SVE feature sets must match, so we're still hunky-dory. This goes wrong if the HW implements SME, but not SVE. In this case, we end-up advertising some SVE features to userspace, even if the HW has none. That's because we never consider whether SVE is actually implemented. Oh well. Fix it by restricting all SVE capabilities to ID_AA64PFR0_EL1.SVE being non-zero. The HWCAPS documentation is amended to reflect the actually checks performed by the kernel. Fixes: 06a916feca2b ("arm64: Expose SVE2 features for userspace") Reported-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: stable@vger.kernel.org Reviewed-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250107-arm64-2024-dpisa-v5-1-7578da51fc3d@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2025-01-08arm64: dts: rockchip: enable hdmi out audio on wolfvision pf5Michael Riesch
Enable HDMI out audio on the WolfVision PF5 mainboard. Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Link: https://lore.kernel.org/r/20241218-b4-wolfvision-pf5-update-v1-2-1d1959858708@wolfvision.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: fix num-channels property of wolfvision pf5 micMichael Riesch
The Rockchip RK3568 PDM block always considers stereo inputs. Therefore, the number of channels must be always an even number, even if a single mono microphone is attached. Fixes: 0be29f76633a ("arm64: dts: rockchip: add wolfvision pf5 mainboard") Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Link: https://lore.kernel.org/r/20241218-b4-wolfvision-pf5-update-v1-1-1d1959858708@wolfvision.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Enable the USB 3.0 port on NanoPi R6C/R6SAnton Kirilov
Enable the USB 3.0 port on FriendlyElec NanoPi R6C/R6S boards. Signed-off-by: Anton Kirilov <anton.kirilov@arm.com> Link: https://lore.kernel.org/r/20241219112532.482891-1-anton.kirilov@arm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6SAnton Kirilov
Fix the SD card detection on FriendlyElec NanoPi R6C/R6S boards. Signed-off-by: Anton Kirilov <anton.kirilov@arm.com> Link: https://lore.kernel.org/r/20241219113145.483205-1-anton.kirilov@arm.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Add FRAM MB85RS128TY to rk3568-mecsbcDavid Jander
The board features a Fujitsu MB85RS128TY FRAM chip connected to spi0 CS 0. Add support for the MB85RS128TY to the device tree. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Jonas Rebmann <jre@pengutronix.de> Link: https://lore.kernel.org/r/20241219-mb85rs128ty-mecsbc-v1-2-77a0e851ef19@pengutronix.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Remove unused i2c2 node from rk3568-mecsbcDavid Jander
One of the pins of i2c2 is actually in use as chip select 0 for spi0. The chip select 0 is used for an FRAM chip, which will be added in the next patch. Remove the i2c2 node from the rk3568-mecsbc device tree. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Jonas Rebmann <jre@pengutronix.de> Link: https://lore.kernel.org/r/20241219-mb85rs128ty-mecsbc-v1-1-77a0e851ef19@pengutronix.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Fix PCIe3 handling for Edgeble-6TOPS ModulesJagan Teki
The Edgeble 6TOPS modules has configured the PCIe3.0 with - 2 lanes on Port1 of pcie3x2 controller for M.2 M-Key - 2 lanes on Port0 of pcie3x4 controller for B and E-Key The, current DT uses opposite controller nodes that indeed uses incorrect reset, regulator nodes. The configuration also uses refclk oscillator that need to enable explicitly in DT to avoid the probe hang on while reading DBI. So, this patch fixes all these essential issues and make this PCIe work properly. Issues fixed are, - Fix the associate controller nodes for M and B, E-Key - Fix the reset gpio handlings - Fix the regulator handlings and naming convensions - Support pcie_refclk oscillator Fixes: 92eaee21abbd ("arm64: dts: rockchip: Add Edgeble NCM6A-IO M.2 B-Key, E-Key") Fixes: 5d85d4c7e03b ("arm64: dts: rockchip: Add Edgeble NCM6A-IO M.2 M-Key") Reported-by: Mitchell Ma <machuang@radxa.com> Co-developed-by: Mitchell Ma <machuang@radxa.com> Signed-off-by: Jagan Teki <jagan@edgeble.ai> Link: https://lore.kernel.org/r/20241221151758.345257-1-jagan@edgeble.ai Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08ARM: dts: mediatek: mt7623: fix IR nodenameRafał Miłecki
Fix following validation error: arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: cir@10013000: $nodename:0: 'cir@10013000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$' from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml# Fixes: 91044f38dae7 ("arm: dts: mt7623: add ir nodes to the mt7623.dtsi file") Cc: linux-media@vger.kernel.org Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240617094634.23173-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2025-01-08arm64: dts: rockchip: Add Radxa E52CFUKAUMI Naoki
Radxa E52C[1] is a compact network computer based on the Rockchip RK3582 SoC: - Dual Cortex-A76 and quad Cortex-A55 CPU - 5TOPS NPU - 2GB/4GB/8GB LPDDR4 RAM - 16GB/32GB/64GB on-board eMMC - microSD card slot - USB 3.0 Type-A HOST port - USB Type-C debug port - USB Type-C power port (5V only) - 2x 2.5GbE ports [1] https://radxa.com/products/network-computer/e52c Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://lore.kernel.org/r/20241226024630.13702-3-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Add BigTreeTech CB2 and Pi2Ivan Sergeev
BigTreeTech CB2 and Pi2 share a lot of hardware configuration, so a common dtsi file was used to define common nodes and properties. This is similar to how BigTreeTech CB1 and Pi are implemented. Signed-off-by: Ivan Sergeev <ivan8215145640@gmail.com> Link: https://lore.kernel.org/r/20250106-bigtreetech-cb2-v7-2-565567e2c0a4@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: kvm: Introduce nvhe stack size constantsKalesh Singh
Refactor nvhe stack code to use NVHE_STACK_SIZE/SHIFT constants, instead of directly using PAGE_SIZE/SHIFT. This makes the code a bit easier to read, without introducing any functional changes. Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Kalesh Singh <kaleshsingh@google.com> Link: https://lore.kernel.org/r/20241112003336.1375584-1-kaleshsingh@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-08KVM: arm64: Fix nVHE stacktrace VA bits maskVincent Donnefort
The hypervisor VA space size depends on both the ID map's (IDMAP_VA_BITS) and the kernel stage-1 (VA_BITS). However, the hypervisor stacktrace decoding is solely relying on VA_BITS. This is especially an issue when VA_BITS < IDMAP_VA_BITS (i.e. VA_BITS is 39-bit): the hypervisor may have addresses bigger than the stacktrace is masking. Align this mask with hyp_va_bits. Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Link: https://lore.kernel.org/r/20250107112821.416591-1-vdonnefort@google.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-08arm64: dts: rockchip: Enable USB 3.0 ports on orangepi-5-plusChen-Yu Tsai
The Orange Pi 5 Plus has its first USB 3.0 interface on the SoC wired directly to the USB type C port next to the MASKROM button, and the second interface wired to a USB 3.0 hub which in turn is connected to the USB 3.0 host ports on the board, as well as the USB 2.0 connection on the M.2 E-key slot. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20241220161240.109253-1-wens@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Add H96 Max V58 TV Box based on RK3588 SoCAlexey Charkov
H96 Max V58 is a compact Rockchip RK3588 based device that ships with Android and is meant for use as a TV connected media box. Its hardware includes: - Rockchip RK3588 SoC with a small aluminium heatsink - 4GB or 8GB LPDDR4 RAM - 32GB or 64GB eMMC 5.1 storage (HS400) - Onboard AP6275P wireless module providing 802.11ax 2x2 MIMO WiFi over PCIe connection and Bluetooth 5.3 over UART with two external detachable antennas - 1x GbE using the onboard GMAC and an RTL8211F PHY - 1x USB 2.0 Type-A (also serves as the Maskrom port) - 1x USB 3.0 Type-A - 1x HDMI 2.1 output - 1x optical SPDIF output - LED line display ("88:88" digits plus icons) driven by an FD6551 IC connected over bitbanged I2C (not yet enabled here) - GPIO connected CIR receiver - Single Rockchip RK806-1 PMIC - 12x onboard ambient LEDs lighting up the bottom of the device - 5v DCIN using a standard round 5.5mm connector Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://lore.kernel.org/r/20250108-rk3588-h96-max-v58-v2-3-522301b905d6@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08arm64: dts: rockchip: Add rk3576 evb1 boardKever Yang
RK3576 EVB1 board features: - Rockchip RK3576 - PMIC: RK806-2x2pcs+DiscretePower - RAM: LPDDR4/4x 2pcsx 32bit - ROM: eMMC5.1 + UFS - LAN x 2 - HDMI TX - SD card slot - PCIe2 slot Add support for pmic, eMMC, SD-card, ADC-KEY, PCIE and GMAC. NOTE: The board has a hardware mux design for - PCIe slot(pcie1) - USB3 host(usb_drd1_dwc3) and default state is switch to USB3. To enable PCIe slot: - hardware: Switch the mux to PCIe side; - dts: disable usb_drd1_dwc3 and enable pcie1; Signed-off-by: Liang Chen <cl@rock-chips.com> Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Link: https://lore.kernel.org/r/20250107074911.550057-8-kever.yang@rock-chips.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08KVM: arm64: Fix FEAT_MTE in pKVMVladimir Murzin
Make sure we do not trap access to Allocation Tags. Fixes: b56680de9c64 ("KVM: arm64: Initialize trap register values in hyp in pKVM") Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Reviewed-by: Fuad Tabba <tabba@google.com> Link: https://lore.kernel.org/r/20250106112421.65355-1-vladimir.murzin@arm.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-08x86/amd_node: Use defines for SMN register offsetsYazen Ghannam
There are more than one SMN index/data pair available for software use. The register offsets are different, but the protocol is the same. Use defines for the SMN offset values and allow the index/data offsets to be passed to the read/write helper function. This eases code reuse with other SMN users in the kernel. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20241206161210.163701-14-yazen.ghannam@amd.com
generated by cgit (git 2.34.1) at 2025-09-22 21:45:17 +0000