summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-01-11MIPS: migrate to generic rule for built-in DTBsMasahiro Yamada
Commit 654102df2ac2 ("kbuild: add generic support for built-in boot DTBs") introduced generic support for built-in DTBs. Select GENERIC_BUILTIN_DTB and BUILTIN_DTB_ALL when the built-in DTB support is enabled. DTBs compiled under arch/mips/boot/dts/ will be wrapped by the generic rule in scripts/Makefile.vmlinux. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11mips: fix shmctl/semctl/msgctl syscall for o32Ism Hong
The commit 275f22148e87 ("ipc: rename old-style shmctl/semctl/msgctl syscalls") switched various architectures to use sys_old_*ctl() with ipc_parse_version, including mips n32/n64. However, for mips o32, commit 0d6040d46817 ("arch: add split IPC system calls where needed") added separate IPC syscalls without properly using the old-style handlers. This causes applications using uClibc-ng to fail with -EINVAL when calling semctl/shmctl/msgctl with IPC_64 flag, as uClibc-ng uses the syscall numbers from kernel headers to determine whether to use the IPC multiplexer or split syscalls. In contrast, glibc is unaffected as it uses a unified feature test macro __ASSUME_DIRECT_SYSVIPC_SYSCALLS (disabled for mips-o32) to make this decision. Fix this by switching the o32 ABI entries for semctl, shmctl and msgctl to use the old-style handlers, matching the behavior of other architectures and fixing compatibility with uClibc-ng. Signed-off-by: Ism Hong <ism.hong@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11mips/math-emu: fix emulation of the prefx instructionMateusz Jończyk
Currently, installation of Debian 12.8 for mipsel fails on machines without an FPU [1]. This is caused by the fact that zstd (which is used for initramfs compression) executes the prefx instruction, which is not emulated properly by the kernel. The prefx (Prefetch Indexed) instruction fetches data from memory into the cache without any side effects. Though functionally unrelated, it requires an FPU [2]. Bytecode format of this instruction ends on "001111" binary: (prefx instruction format) & 0x0000003f = 0x0000000f The code in fpux_emu() runs like so: #define MIPSInst(x) x #define MIPSInst_FMA_FFMT(x) (MIPSInst(x) & 0x00000007) #define MIPSInst_FUNC(x) (MIPSInst(x) & 0x0000003f) enum cop1x_func { ..., pfetch_op = 0x0f, ... }; ... switch (MIPSInst_FMA_FFMT(ir)) { ... case 0x3: if (MIPSInst_FUNC(ir) != pfetch_op) return SIGILL; /* ignore prefx operation */ break; default: return SIGILL; } That snippet above contains a logic error and the if (MIPSInst_FUNC(ir) != pfetch_op) comparison always fires. When MIPSInst_FUNC(ir) is equal to pfetch_op, ir must end on 001111 binary. In this case, MIPSInst_FMA_FFMT(ir) must be equal to 0x7, which does not match that case label. This causes emulation failure for the prefx instruction. Fix it. This has been broken by commit 919af8b96c89 ("MIPS: Make definitions of MIPSInst_FMA_{FUNC,FMTM} consistent with MIPS64 manual") which modified the MIPSInst_FMA_FFMT macro without updating the users. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: stable@vger.kernel.org # after 3 weeks Cc: Dengcheng Zhu <dzhu@wavecomp.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Ming Wang <wangming01@loongson.cn> Cc: Tiezhu Yang <yangtiezhu@loongson.cn> Fixes: 919af8b96c89 ("MIPS: Make definitions of MIPSInst_FMA_{FUNC,FMTM} consistent with MIPS64 manual") [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091858 [2] MIPS Architecture For Programmers Volume II-A: The MIPS32 Instruction Set Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: Loongson: Add comments for interface_infoKexy Biscuit
Clarify meanings of members of interface_info, especially for .size, which does not define the ROM size. Suggested-by: Icenowy Zheng <uwu@icenowy.me> Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Acked-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: Loongson64: remove ROM Size unit in boardinfoKexy Biscuit
Per Appendix A.7 in Q/LS 0013-2014 (龙芯CPU开发系统固件与内核接口规范 V2.2, lit. Loongson DevSys Firmware Kernel Interface Specification V2.2), interface_info.size is size of this interface, not size of the LEFI BIOS ROM. In any case, the BIOS ROM Size just cannot be several kilobytes (KB) on Loongson64 LEFI platforms. Reported-by: Mingcong Bai <jeffbai@aosc.io> Suggested-by: Icenowy Zheng <uwu@icenowy.me> Fixes: 6c1bfbd9df8c ("MIPS: Loongson64: Add /sys/firmware/lefi/boardinfo") Cc: stable@vger.kernel.org Signed-off-by: Kexy Biscuit <kexybiscuit@aosc.io> Acked-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: traps: Use str_enabled_disabled() in parity_protection_init()Thorsten Blum
Remove hard-coded strings by using the str_enabled_disabled() helper function. Use pr_info() instead of printk(KERN_INFO) to silence multiple checkpatch warnings. Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: ftrace: Declare ftrace_get_parent_ra_addr() as staticWangYuli
Declare ftrace_get_parent_ra_addr() as static to suppress clang compiler warning that 'no previous prototype'. This function is not intended to be called from other parts. Fix follow error with clang-19: arch/mips/kernel/ftrace.c:251:15: error: no previous prototype for function 'ftrace_get_parent_ra_addr' [-Werror,-Wmissing-prototypes] 251 | unsigned long ftrace_get_parent_ra_addr(unsigned long self_ra, unsigned long | ^ arch/mips/kernel/ftrace.c:251:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 251 | unsigned long ftrace_get_parent_ra_addr(unsigned long self_ra, unsigned long | ^ | static 1 error generated. Signed-off-by: WangYuli <wangyuli@uniontech.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11Revert "MIPS: csrc-r4k: Select HAVE_UNSTABLE_SCHED_CLOCK if SMP && 64BIT"Xi Ruoyao
This reverts commit 426fa8e4fe7bb914b5977cbce453a9926bf5b2e6. The commit has caused two issues on Loongson 3A4000: 1. The timestamp in dmesg become erratic, like: [3.736957] amdgpu 0000:04:00.0: ... ... [3.748895] [drm] Initialized amdgpu ... ... [18446744073.381141] amdgpu 0000:04:00:0: ... ... [1.613326] igb 0000:03:00.0 enp3s0: ... ... 2. More seriously, some workloads (for example, the test stdlib/test-cxa_atexit2 in the Glibc test suite) triggers an RCU stall and hang the system with a high probably (4 hangs out of 5 tests). Revert this commit to use jiffie on Loongson MIPS systems and fix these issues for now. The root cause may need more investigation. Cc: stable@vger.kernel.org # 6.11+ Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: Fix the wrong format specifierliujing
Make a minor change to eliminate a static checker warning. The type of cpu is unsigned int, so the correct format specifier should be %u instead of %d. Signed-off-by: liujing <liujing@cmss.chinamobile.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: Add a blank line after __HEADRong Xu
Add a blank line after __HEAD in the text section. The __HEAD symbol was added in commit 52892ed6b03a ("MIPS: Place __kernel_entry at the beginning of text section"). Signed-off-by: Rong Xu <xur@google.com> Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> ---Changelog-- Added suggested-by. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11MIPS: kernel: Rename read/write_c0_ecc to read/writec0_errctlThomas Bogendoerfer
CP0 register 26 is used as ECC register for legacy cores, but newer cores (MIPS32/MIPS64) use it as an ErrCtl register. Since the kernel only uses CP0 26 as ErrCtl register rename the access functions to the more fitting name. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-01-11KVM: arm64: Explicitly handle BRBE traps as UNDEFINEDMark Rutland
The Branch Record Buffer Extension (BRBE) adds a number of system registers and instructions which we don't currently intend to expose to guests. Our existing logic handles this safely, but this could be improved with some explicit handling of BRBE. KVM currently hides BRBE from guests: the cpufeature code's ftr_id_aa64dfr0[] table doesn't have an entry for the BRBE field, and so this will be zero in the sanitised value of ID_AA64DFR0 exposed to guests via read_sanitised_id_aa64dfr0_el1(). KVM currently traps BRBE usage from guests: the default configuration of the fine-grained trap controls HDFGRTR_EL2.{nBRBDATA,nBRBCTL,nBRBIDR} and HFGITR_EL2.{nBRBINJ_nBRBIALL} cause these to be trapped to EL2. Well-behaved guests shouldn't try to use the registers or instructions, but badly-behaved guests could use these, resulting in unnecessary warnings from KVM before it injects an UNDEF, e.g. | kvm [197]: Unsupported guest access at: 401c98 | { Op0( 2), Op1( 1), CRn( 9), CRm( 0), Op2( 0), func_read }, | kvm [197]: Unsupported guest access at: 401d04 | { Op0( 2), Op1( 1), CRn( 9), CRm( 0), Op2( 1), func_read }, | kvm [197]: Unsupported guest access at: 401d70 | { Op0( 2), Op1( 1), CRn( 9), CRm( 2), Op2( 0), func_read }, | kvm [197]: Unsupported guest access at: 401ddc | { Op0( 2), Op1( 1), CRn( 9), CRm( 1), Op2( 0), func_read }, | kvm [197]: Unsupported guest access at: 401e48 | { Op0( 2), Op1( 1), CRn( 9), CRm( 1), Op2( 1), func_read }, | kvm [197]: Unsupported guest access at: 401eb4 | { Op0( 2), Op1( 1), CRn( 9), CRm( 1), Op2( 2), func_read }, | kvm [197]: Unsupported guest access at: 401f20 | { Op0( 2), Op1( 1), CRn( 9), CRm( 0), Op2( 2), func_read }, | kvm [197]: Unsupported guest access at: 401f8c | { Op0( 1), Op1( 1), CRn( 7), CRm( 2), Op2( 4), func_write }, | kvm [197]: Unsupported guest access at: 401ff8 | { Op0( 1), Op1( 1), CRn( 7), CRm( 2), Op2( 5), func_write }, As with other features that we know how to handle, these warnings aren't particularly interesting, and we can simply treat these as UNDEFINED without any warning. Add the necessary fine-grained undef configuration to make this happen, as suggested by Marc Zyngier: https://lore.kernel.org/linux-arm-kernel/86r0czk6wd.wl-maz@kernel.org/ At the same time, update read_sanitised_id_aa64dfr0_el1() to hide BRBE from guests, as we do for SPE. This will prevent accidentally exposing BRBE to guests if/when ftr_id_aa64dfr0[] gains a BRBE entry. Cc: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250109223836.419240-1-robh@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-11KVM: arm64: vgic: Use str_enabled_disabled() in vgic_v3_probe()Thorsten Blum
Remove hard-coded strings by using the str_enabled_disabled() helper function. Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20250110225310.369980-2-thorsten.blum@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-01-11powerpc/prom_init: Use IS_ENABLED()Michael Ellerman
Use IS_ENABLED() for the device tree checks, so that more code is checked by the compiler without having to build all the different configurations. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20241218113159.422821-1-mpe@ellerman.id.au
2025-01-11powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDWGaurav Batra
Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well. Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20241206210039.93172-1-gbatra@linux.ibm.com
2025-01-10Merge tag 'riscv-for-linus-6.13-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - a handful of selftest fixes - fix a memory leak in relocation processing during module loading - avoid sleeping in die() - fix kprobe instruction slot address calculations - fix DT node reference leak in SBI idle probing - avoid initializing out of bounds pages on sparse vmemmap systems with a gap at the start of their physical memory map - fix backtracing through exceptions - _Q_PENDING_LOOPS is now defined whenever QUEUED_SPINLOCKS=y - local labels in entry.S are now marked with ".L", which prevents them from trashing backtraces - a handful of fixes for SBI-based performance counters * tag 'riscv-for-linus-6.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: drivers/perf: riscv: Do not allow invalid raw event config drivers/perf: riscv: Return error for default case drivers/perf: riscv: Fix Platform firmware event data tools: selftests: riscv: Add test count for vstate_prctl tools: selftests: riscv: Add pass message for v_initval_nolibc riscv: use local label names instead of global ones in assembly riscv: qspinlock: Fixup _Q_PENDING_LOOPS definition riscv: stacktrace: fix backtracing through exceptions riscv: mm: Fix the out of bound issue of vmemmap address cpuidle: riscv-sbi: fix device node release in early exit of for_each_possible_cpu riscv: kprobes: Fix incorrect address calculation riscv: Fix sleeping in invalid context in die() riscv: module: remove relocation_head rel_entry member allocation riscv: selftests: Fix warnings pointer masking test
2025-01-10arm64: tegra: Fix Tegra234 PCIe interrupt-mapBrad Griffis
For interrupt-map entries, the DTS specification requires that #address-cells is defined for both the child node and the interrupt parent. For the PCIe interrupt-map entries, the parent node ("gic") has not specified #address-cells. The existing layout of the PCIe interrupt-map entries indicates that it assumes that #address-cells is zero for this node. Explicitly set #address-cells to zero for "gic" so that it complies with the device tree specification. NVIDIA EDK2 works around this issue by assuming #address-cells is zero in this scenario, but that workaround is being removed and so this update is needed or else NVIDIA EDK2 cannot successfully parse the device tree and the board cannot boot. Fixes: ec142c44b026 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra234 DT") Signed-off-by: Brad Griffis <bgriffis@nvidia.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241213235602.452303-1-bgriffis@nvidia.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-01-10Merge tag 'v6.13-rockchip-dtsfixes1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes Fixed card-detect on one board and some missing properties added. * tag 'v6.13-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: add hevc power domain clock to rk3328 arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6S arm64: dts: rockchip: rename rfkill label for Radxa ROCK 5B arm64: dts: rockchip: add reset-names for combphy on rk3568 Link: https://lore.kernel.org/r/2914560.yaVYbkx8dN@diego Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-10perf/x86/intel/uncore: Support more units on Granite RapidsKan Liang
The same CXL PMONs support is also avaiable on GNR. Apply spr_uncore_cxlcm and spr_uncore_cxldp to GNR as well. The other units were broken on early HW samples, so they were ignored in the early enabling patch. The issue has been fixed and verified on the later production HW. Add UPI, B2UPI, B2HOT, PCIEX16 and PCIEX8 for GNR. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Eric Hu <eric.hu@intel.com> Link: https://lkml.kernel.org/r/20250108143017.1793781-2-kan.liang@linux.intel.com
2025-01-10perf/x86/intel/uncore: Clean up func_idKan Liang
The below warning may be triggered on GNR when the PCIE uncore units are exposed. WARNING: CPU: 4 PID: 1 at arch/x86/events/intel/uncore.c:1169 uncore_pci_pmu_register+0x158/0x190 The current uncore driver assumes that all the devices in the same PMU have the exact same devfn. It's true for the previous platforms. But it doesn't work for the new PCIE uncore units on GNR. The assumption doesn't make sense. There is no reason to limit the devices from the same PMU to the same devfn. Also, the current code just throws the warning, but still registers the device. The WARN_ON_ONCE() should be removed. The func_id is used by the later event_init() to check if a event->pmu has valid devices. For cpu and mmio uncore PMUs, they are always valid. For pci uncore PMUs, it's set when the PMU is registered. It can be replaced by the pmu->registered. Clean up the func_id. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Eric Hu <eric.hu@intel.com> Link: https://lkml.kernel.org/r/20250108143017.1793781-1-kan.liang@linux.intel.com
2025-01-11modules: Support extended MODVERSIONS infoMatthew Maurer
Adds a new format for MODVERSIONS which stores each field in a separate ELF section. This initially adds support for variable length names, but could later be used to add additional fields to MODVERSIONS in a backwards compatible way if needed. Any new fields will be ignored by old user tooling, unlike the current format where user tooling cannot tolerate adjustments to the format (for example making the name field longer). Since PPC munges its version records to strip leading dots, we reproduce the munging for the new format. Other architectures do not appear to have architecture-specific usage of this information. Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Matthew Maurer <mmaurer@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2025-01-10KVM: SVM: Use str_enabled_disabled() helper in svm_hardware_setup()Thorsten Blum
Remove hard-coded strings by using the str_enabled_disabled() helper function. Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://lore.kernel.org/r/20250110101100.272312-2-thorsten.blum@linux.dev Signed-off-by: Sean Christopherson <seanjc@google.com>
2025-01-10ARM: riscpc: make ecard_bus_type constantKunwu Chan
Since commit d492cc2573a0 ("driver core: device.h: make struct bus_type a const *"), the driver core can properly handle constant struct bus_type, move the ecard_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kunwu Chan <chentao@kylinos.cn> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240823081444.150976-1-kunwu.chan@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-01-10arm64: Remove duplicate included headerThorsten Blum
The header asm/unistd_compat_32.h is included whether CONFIG_COMPAT is defined or not. Include it only once and remove the following make includecheck warning: asm/unistd_compat_32.h is included more than once Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250109104636.124507-2-thorsten.blum@linux.dev Signed-off-by: Will Deacon <will@kernel.org>
2025-01-10um: rtc: use RTC time when calculating the alarmBenjamin Berg
The kernel realtime and the current RTC time may have a (small) offset. Should the kernel time be slightly in the future, then the timeout is zero. This is problematic in time-travel mode, as a zero timeout can be correctly configured and time never advances. Replace the kernel realtime read with a read of the actual persistent RTC clock. Also, for time-travel, calculate the exact nanoseconds needed for the clock to advance. Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Co-developed-by: Avraham Stern <avraham.stern@intel.com> Link: https://patch.msgid.link/20241217204906.1408011-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Remove unused user_context functionTiwei Bie
It's no longer used since commit 6aa802ce6acc ("uml: throw out CHOOSE_MODE"). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-10-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Remove unused THREAD_NAME_LEN macroTiwei Bie
It's no longer used since commit 42fda66387da ("uml: throw out CONFIG_MODE_TT"). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-9-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Remove unused PGD_BOUND macroTiwei Bie
It's no longer used since commit 11100b1dfb6e ("uml: delete unused code"). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-8-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Mark setup_env_path as __initTiwei Bie
It's only invoked during boot from main(). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-7-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Mark install_fatal_handler as __initTiwei Bie
It's only invoked during boot from main(). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-6-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Mark set_stklim as __initTiwei Bie
It's only invoked during boot from main(). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-5-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Mark get_top_address as __initTiwei Bie
It's only invoked during boot from linux_main(). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-4-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Mark parse_cache_line as __initTiwei Bie
It's only invoked during boot from get_host_cpu_features(). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-3-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Mark parse_host_cpu_flags as __initTiwei Bie
It's only invoked during boot from get_host_cpu_features(). Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128083137.2219830-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Count iomem_size only once in physmem calculationTiwei Bie
When calculating max_physmem, we've already factored in the space used by iomem. We don't need to subtract it again. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128081939.2216246-4-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Remove obsolete fixmap supportTiwei Bie
It was added to support highmem. But since the highmem support has been removed by commit a98a6d864d3b ("um: Remove broken highmem support"), it is no longer needed. Remove it to simplify the code. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128081939.2216246-3-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10um: Remove unused MODULES_LEN macroTiwei Bie
It's not used anywhere. And its definition doesn't seem right. Signed-off-by: Tiwei Bie <tiwei.btw@antgroup.com> Link: https://patch.msgid.link/20241128081939.2216246-2-tiwei.btw@antgroup.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-01-10m68k: libgcc: Fix lvalue abuse in umul_ppmm()Geert Uytterhoeven
lib/muldi3.c:53:28: warning: asm output is not an lvalue lib/muldi3.c:53:28: warning: asm output is not an lvalue lib/muldi3.c:53:28: error: not addressable lib/muldi3.c:53:28: warning: generating address of non-lvalue (11) lib/muldi3.c:53:28: warning: generating address of non-lvalue (11) Fix the lvalue warnings by replacing the casts on the output operands by intermediate variables of the right type. Fix the "not addressable" error by replacing the cast on the second input operand by an intermediate variable, too. Treat the other input operand the same for consistency. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501030516.uZrwnuQQ-lkp@intel.com/ Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Link: https://lore.kernel.org/c408cfb85bfde8929dcaa4ebea29ade4e1452d8e.1736356696.git.geert@linux-m68k.org
2025-01-10Merge tag 'v6.13-rc6' into drm-nextDave Airlie
This backmerges Linux 6.13-rc6 this is need for the newer pulls. Signed-off-by: Dave Airlie <airlied@redhat.com>
2025-01-10hyperv: Do not overlap the hvcall IO areas in hv_vtl_apicid_to_vp_id()Roman Kisel
The Top-Level Functional Specification for Hyper-V, Section 3.6 [1, 2], disallows overlapping of the input and output hypercall areas, and hv_vtl_apicid_to_vp_id() overlaps them. Use the output hypercall page of the current vCPU for the hypercall. [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercall-interface [2] https://github.com/MicrosoftDocs/Virtualization-Documentation/tree/main/tlfs Reported-by: Michael Kelley <mhklinux@outlook.com> Closes: https://lore.kernel.org/lkml/SN6PR02MB4157B98CD34781CC87A9D921D40D2@SN6PR02MB4157.namprd02.prod.outlook.com/ Signed-off-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Link: https://lore.kernel.org/r/20250108222138.1623703-6-romank@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250108222138.1623703-6-romank@linux.microsoft.com>
2025-01-10hyperv: Do not overlap the hvcall IO areas in get_vtl()Roman Kisel
The Top-Level Functional Specification for Hyper-V, Section 3.6 [1, 2], disallows overlapping of the input and output hypercall areas, and get_vtl(void) does overlap them. Use the output hypercall page of the current vCPU for the hypercall. [1] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/hypercall-interface [2] https://github.com/MicrosoftDocs/Virtualization-Documentation/tree/main/tlfs Fixes: 8387ce06d70b ("x86/hyperv: Set Virtual Trust Level in VMBus init message") Signed-off-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Tianyu Lan <tiala@microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Link: https://lore.kernel.org/r/20250108222138.1623703-5-romank@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20250108222138.1623703-5-romank@linux.microsoft.com>
2025-01-10x86/hyperv: Don't assume cpu_possible_mask is denseMichael Kelley
Current code allocates the hv_vp_assist_page array with size num_possible_cpus(). This code assumes cpu_possible_mask is dense, which is not true in the general case per [1]. If cpu_possible_mask is sparse, the array might be indexed by a value beyond the size of the array. However, the configurations that Hyper-V provides to guest VMs on x86 hardware, in combination with how x86 code assigns Linux CPU numbers, *does* always produce a dense cpu_possible_mask. So the dense assumption is not currently causing failures. But for robustness against future changes in how cpu_possible_mask is populated, update the code to no longer assume dense. The correct approach is to allocate the array with size "nr_cpu_ids". While this leaves unused array entries corresponding to holes in cpu_possible_mask, the holes are assumed to be minimal and hence the amount of memory wasted by unused entries is minimal. [1] https://lore.kernel.org/lkml/SN6PR02MB4157210CC36B2593F8572E5ED4692@SN6PR02MB4157.namprd02.prod.outlook.com/ Signed-off-by: Michael Kelley <mhklinux@outlook.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20241003035333.49261-2-mhklinux@outlook.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <20241003035333.49261-2-mhklinux@outlook.com>
2025-01-10hyperv: Remove the now unused hyperv-tlfs.h filesNuno Das Neves
Remove all hyperv-tlfs.h files. These are no longer included anywhere. hyperv/hvhdk.h serves the same role, but with an easier path for adding new definitions. Remove the relevant lines in MAINTAINERS. Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Link: https://lore.kernel.org/r/1732577084-2122-6-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1732577084-2122-6-git-send-email-nunodasneves@linux.microsoft.com>
2025-01-10hyperv: Switch from hyperv-tlfs.h to hyperv/hvhdk.hNuno Das Neves
Switch to using hvhdk.h everywhere in the kernel. This header includes all the new Hyper-V headers in include/hyperv, which form a superset of the definitions found in hyperv-tlfs.h. This makes it easier to add new Hyper-V interfaces without being restricted to those in the TLFS doc (reflected in hyperv-tlfs.h). To be more consistent with the original Hyper-V code, the names of some definitions are changed slightly. Update those where needed. Update comments in mshyperv.h files to point to include/hyperv for adding new definitions. Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Signed-off-by: Roman Kisel <romank@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Link: https://lore.kernel.org/r/1732577084-2122-5-git-send-email-nunodasneves@linux.microsoft.com Link: https://lore.kernel.org/r/20250108222138.1623703-3-romank@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2025-01-10arm64: defconfig: Enable Rockchip extensions for Synopsys DW HDMI QPCristian Ciocaltea
Enable Rockchip specific extensions for Synopsys DesignWare HDMI Quad-Pixel (QP) driver. This is needed to provide HDMI output support for the boards based on RK3588 SoC. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20241202-dw-hdmi-qp-rk-defconfig-v1-1-38757fc053d0@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-10arm64: defconfig: Enable RFKILL GPIONicolas Dufresne
Enable as a module the RFKILL GPIO driver. This is needed to power WiFi and Bluetooth radio on various RK3588 board. Without this module, rfkill will report the switch has hard blocked, which prevents using the WiFi or Bluetooth feature. Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Link: https://lore.kernel.org/r/20241218-rk3588-rfkill-gpio-config-v1-1-dfdf464f97d4@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09arm64: dts: qcom: x1e80100-romulus: Update firmware nodesJoel Stanley
Other x1e machines use _dtbs.elf for these firmwares, which matches the filenames shipped by Windows. Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250108124500.44011-1-joel@jms.id.au Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-01-10arm64: dts: rockchip: add DTs for Firefly ITX-3588J and its Core-3588J SoMShimrra Shai
Add the device tree and Makefile update. Signed-off-by: Shimrra Shai <shimrrashai@gmail.com> Link: https://lore.kernel.org/r/20241216214152.58387-3-shimrrashai@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09arm64: dts: rockchip: Add Orange Pi 5 Max boardJimmy Hon
The RK3588 Single Board Computer includes - eMMC - microSD - UART - 2 PWM LEDs - RTC - RTL8125 network controller on PCIe 2.0x1. - M.2 M-key connector routed to PCIe 3.0x4 - PWM controlled heat sink fan. - 2 USB2 ports - lower USB3 port - upper USB3 port with OTG capability - Mali GPU - SPI NOR flash - Mask Rom button - Analog audio using es8388 codec via the headset jack and onboard mic - HDMI0 - HDMI1 the vcc5v0_usb30 regulator shares the same enable gpio pin as the vcc5v0_usb20 regulator. The Orange Pi 5 Max and Orange Pi 5 Ultra are both credit-card sized boards with similar layout, so these boards will share a common dtsi. The 5 Max has an extra HDMI0 while the 5 Ultra has a HDMI IN instead. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250109051619.1825-4-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09arm64: dts: rockchip: refactor common rk3588-orangepi-5.dtsiJimmy Hon
Orange Pi now has multiple SBCs using the RK3588. Refactor the common parts of the Orange Pi 5 Plus DTS so it can be shared with the 5 Max and the 5 Ultra. Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com> Link: https://lore.kernel.org/r/20250109051619.1825-2-honyuenkwun@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
generated by cgit (git 2.34.1) at 2025-07-18 20:00:30 +0000