summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2023-10-07parisc: Fix crash with nr_cpus=1 optionHelge Deller
John David Anglin reported that giving "nr_cpus=1" on the command line causes a crash, while "maxcpus=1" works. Reported-by: John David Anglin <dave.anglin@bell.net> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.18+
2023-10-07riscv: dts: sophgo: add Milk-V Duo board device treeJisheng Zhang
Milk-V Duo[1] board is an embedded development platform based on the CV1800B chip. Add minimal device tree files for the development board. Support basic uart drivers, so supports booting to a basic shell. Link: https://milkv.io/duo [1] Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-10-07riscv: dts: sophgo: add initial CV1800B SoC device treeJisheng Zhang
Add initial device tree for the CV1800B RISC-V SoC by SOPHGO. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-10-07riscv: defconfig: enable SOPHGO SoCChen Wang
Enable SOPHGO SoC config in defconfig to allow the default upstream kernel to boot on Milk-V Pioneer board. Acked-by: Chao Wei <chao.wei@sophgo.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> [conor: fix the ordering] Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-10-07riscv: dts: sophgo: add Milk-V Pioneer board device treeChen Wang
Milk-V Pioneer [1] is a developer motherboard based on SG2042 in a standard mATX form factor. Currently only support booting into console with only uart enabled, other features will be added soon later. Link: https://milkv.io/pioneer [1] Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Chao Wei <chao.wei@sophgo.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-10-07riscv: dts: add initial Sophgo SG2042 SoC device treeChen Wang
Milk-V Pioneer motherboard is powered by SG2042. SG2042 is server grade chip with high performance, low power consumption and high data throughput. Key features: - 64 RISC-V cpu cores - 4 cores per cluster, 16 clusters on chip - More info is available at [1]. Currently only support booting into console with only uart, other features will be added soon later. Link: https://en.sophgo.com/product/introduce/sg2042.html [1] Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Chao Wei <chao.wei@sophgo.com> Co-developed-by: Xiaoguang Xing <xiaoguang.xing@sophgo.com> Signed-off-by: Xiaoguang Xing <xiaoguang.xing@sophgo.com> Co-developed-by: Inochi Amaoto <inochiama@outlook.com> Signed-off-by: Inochi Amaoto <inochiama@outlook.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-10-07x86/idle: Disable IBRS when CPU is offline to improve single-threaded ↵Waiman Long
performance Commit bf5835bcdb96 ("intel_idle: Disable IBRS during long idle") disables IBRS when the CPU enters long idle. However, when a CPU becomes offline, the IBRS bit is still set when X86_FEATURE_KERNEL_IBRS is enabled. That will impact the performance of a sibling CPU. Mitigate this performance impact by clearing all the mitigation bits in SPEC_CTRL MSR when offline. When the CPU is online again, it will be re-initialized and so restoring the SPEC_CTRL value isn't needed. Add a comment to say that native_play_dead() is a __noreturn function, but it can't be marked as such to avoid confusion about the missing MSR restoration code. When DPDK is running on an isolated CPU thread processing network packets in user space while its sibling thread is idle. The performance of the busy DPDK thread with IBRS on and off in the sibling idle thread are: IBRS on IBRS off ------- -------- packets/second: 7.8M 10.4M avg tsc cycles/packet: 282.26 209.86 This is a 25% performance degradation. The test system is a Intel Xeon 4114 CPU @ 2.20GHz. [ mingo: Extended the changelog with performance data from the 0/4 mail. ] Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20230727184600.26768-3-longman@redhat.com
2023-10-07x86/speculation: Add __update_spec_ctrl() helperWaiman Long
Add a new __update_spec_ctrl() helper which is a variant of update_spec_ctrl() that can be used in a noinstr function. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20230727184600.26768-2-longman@redhat.com
2023-10-07ARM: OMAP: timer32K: fix all kernel-doc warningsRandy Dunlap
Fix kernel-doc warnings reported by the kernel test robot: timer32k.c:186: warning: cannot understand function prototype: 'struct timespec64 persistent_ts; ' timer32k.c:191: warning: Function parameter or member 'ts' not described in 'omap_read_persistent_clock64' timer32k.c:216: warning: Function parameter or member 'vbase' not described in 'omap_init_clocksource_32k' timer32k.c:216: warning: Excess function parameter 'pbase' description in 'omap_init_clocksource_32k' timer32k.c:216: warning: Excess function parameter 'size' description in 'omap_init_clocksource_32k' timer32k.c:216: warning: No description found for return value of 'omap_init_clocksource_32k' Fixes: a451570c008b ("ARM: OMAP: 32k counter: Provide y2038-safe omap_read_persistent_clock() replacement") Fixes: 1fe97c8f6a1d ("ARM: OMAP: Make OMAP clocksource source selection using kernel param") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202310070106.8QSyJOm3-lkp@intel.com/ Cc: Arnd Bergmann <arnd@arndb.de> Cc: Vaibhav Hiremath <hvaibhav@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Xunlei Pang <pang.xunlei@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: linux-omap@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Message-ID: <20231007001603.24972-1-rdunlap@infradead.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: omap2: fix a debug printkDan Carpenter
The %pR format string takes a pointer to struct resource, but this is passing a pointer to a pointer which it will print wrong information. Fixes: c63f5b454885 ("ARM: omap2: Use of_range_to_resource() for "ranges" parsing") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Message-ID: <c126dc33-233a-4776-806f-9dff0e73a181@moroto.mountain> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: omap4-embt2ws: Fix pinctrl single node name warningTony Lindgren
Looks like one pinctrl single binding warning sneaked in while we were implementing the yaml binding. Let's fix the 'pinmux-wl12xx-gpio' does not match any of the regexes warning by adding -pins suffix. Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: motorola-mapphone: Add mdm6600 sleep pinsTony Lindgren
The sleep pins never got added earlier probably because the driver was not behaving correctly with the sleep pins. We need the sleep pins to prevent the modem from waking up on it's own if the reset pin glitches in deeper SoC idle states. Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Message-ID: <20230911035828.36984-1-tony@atomide.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: am3517: Configure ethernet aliasAdam Ford
The AM3517 has one ethernet controller called davinci_emac. Configuring the alias allows the MAC address to be passed from the bootloader to Linux. Signed-off-by: Adam Ford <aford173@gmail.com> Message-ID: <20230906095143.99806-2-aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: am3517-evm: Enable Ethernet PHY InterruptAdam Ford
The Ethernet PHY interrupt pin is routed to GPIO_58. Create a PHY node to configure this GPIO for the interrupt to avoid polling. Signed-off-by: Adam Ford <aford173@gmail.com> Message-ID: <20231005000402.50879-2-aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: am3517-evm: Fix LED3/4 pinmuxAdam Ford
The pinmux for LED3 and LED4 are incorrectly attached to the omap3_pmx_core when they should be connected to the omap3_pmx_wkup pin mux. This was likely masked by the fact that the bootloader used to do all the pinmuxing. Fixes: 0dbf99542caf ("ARM: dts: am3517-evm: Add User LEDs and Pushbutton") Signed-off-by: Adam Ford <aford173@gmail.com> Message-ID: <20231005000402.50879-1-aford173@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: omap3-gta04: Drop superfluous omap36xx compatibleAndreas Kemnade
Drop omap36xx compatible as done in other omap3630 devices. This has apparently fallen through the lattice. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Message-ID: <20231004065323.2408615-1-andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-07ARM: dts: omap: omap4-embt2ws: Add IMU at control unitAndreas Kemnade
Add also the level-shifter flag to avoid probe failure in magnetometer probe. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Message-ID: <20230927173245.2151083-4-andreas@kemnade.info> Signed-off-by: Tony Lindgren <tony@atomide.com>
2023-10-06mm: add statistics for PUD level pagetableBaolin Wang
Recently, we found that cross-die access to pagetable pages on ARM64 machines can cause performance fluctuations in our business. Currently, there are no PMU events available to track this situation on our ARM64 machines, so accurate pagetable accounting can help to analyze this issue, but now the PUD level pagetable accounting is missed. So introduce pagetable_pud_ctor/dtor() to help to get accurate PUD pagetable accounting, as well as converting the architectures which use generic PUD pagetable allocation to add corresponding PUD pagetable accounting. Moreover this patch will mark the PUD level pagetable with PG_table flag, which will help to do sanity validation in unpoison_memory(). On my testing machine, I can see more pagetables statistics after the patch with page-types tool: Before patch: flags page-count MB symbolic-flags long-symbolic-flags 0x0000000004000000 27326 106 __________________________g_________________ pgtable After patch: 0x0000000004000000 27541 107 __________________________g_________________ pgtable Link: https://lkml.kernel.org/r/876c71c03a7e69c17722a690e3225a4f7b172fb2.1695017383.git.baolin.wang@linux.alibaba.com Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> Acked-by: Mike Rapoport (IBM) <rppt@kernel.org> Acked-by: Vishal Moola (Oracle) <vishal.moola@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-10-06riscv: fix set_huge_pte_at() for NAPOT mappings when a swap entry is setAlexandre Ghiti
We used to determine the number of page table entries to set for a NAPOT hugepage by using the pte value which actually fails when the pte to set is a swap entry. So take advantage of a recent fix for arm64 reported in [1] which introduces the size of the mapping as an argument of set_huge_pte_at(): we can then use this size to compute the number of page table entries to set for a NAPOT region. Link: https://lkml.kernel.org/r/20230928151846.8229-3-alexghiti@rivosinc.com Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reported-by: Ryan Roberts <ryan.roberts@arm.com> Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1] Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Qinglin Pan <panqinglin2020@iscas.ac.cn> Cc: Conor Dooley <conor@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-10-06riscv: handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panickingAlexandre Ghiti
Patch series "Fix set_huge_pte_at()". A recent report [1] from Ryan for arm64 revealed that we do not handle swap entries when setting a hugepage backed by a NAPOT region (the contpte riscv equivalent). As explained in [1], the issue was discovered by a new test in kselftest which uses poison entries, but the symptoms are different from arm64 though: - the riscv kernel bugs because we do not handle VM_FAULT_HWPOISON*, this is fixed by patch 1, - after that, the test passes because the first pte_napot() fails (the poison entry does not have the N bit set), and then we only set the first page table entry covering the NAPOT hugepage, which is enough for hugetlb_fault() to correctly raise a VM_FAULT_HWPOISON wherever we write in this mapping since only this first page table entry is checked (see https://elixir.bootlin.com/linux/v6.6-rc3/source/mm/hugetlb.c#L6071). But this seems fragile so patch 2 sets all page table entries of a NAPOT mapping. [1]: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ This patch (of 2): We used to panic when such faults were encountered but we should handle those faults gracefully for userspace by sending a SIGBUS to the process, like most architectures do. Link: https://lkml.kernel.org/r/20230928151846.8229-1-alexghiti@rivosinc.com Link: https://lkml.kernel.org/r/20230928151846.8229-2-alexghiti@rivosinc.com Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Andrew Jones <ajones@ventanamicro.com> Cc: Conor Dooley <conor@kernel.org> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Qinglin Pan <panqinglin2020@iscas.ac.cn> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-10-06arm64: dts: mediatek: mt8195: Set DSU PMU status to failNícolas F. R. A. Prado
The DSU PMU allows monitoring performance events in the DSU cluster, which is done by configuring and reading back values from the DSU PMU system registers. However, for write-access to be allowed by ELs lower than EL3, the EL3 firmware needs to update the setting on the ACTLR3_EL3 register, as it is disallowed by default. That configuration is not done on the firmware used by the MT8195 SoC, as a consequence, booting a MT8195-based machine like mt8195-cherry-tomato-r2 with CONFIG_ARM_DSU_PMU enabled hangs the kernel just as it writes to the CLUSTERPMOVSCLR_EL1 register, since the instruction faults to EL3, and BL31 apparently just re-runs the instruction over and over. Mark the DSU PMU node in the Devicetree with status "fail", as the machine doesn't have a suitable firmware to make use of it from the kernel, and allowing its driver to probe would hang the kernel. Fixes: 37f2582883be ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230720200753.322133-1-nfraprado@collabora.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-5-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-06arm64: dts: mediatek: fix t-phy unit nameEugen Hristev
dtbs_check throws a warning at t-phy nodes: Warning (unit_address_vs_reg): /t-phy@1a243000: node has a unit name, but no reg or ranges property Warning (unit_address_vs_reg): /soc/t-phy@11c00000: node has a unit name, but no reg or ranges property The ranges is empty thus removing the `@1a243000`, `@11c00000` from the node name. Fixes: 6029cae696c8 ("arm64: dts: mediatek: mt7622: harmonize node names and compatibles") Fixes: 918aed7abd2d ("arm64: dts: mt7986: add pcie related device nodes") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230814093931.9298-2-eugen.hristev@collabora.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-4-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-06arm64: dts: mediatek: mt8195-demo: update and reorder reserved memory regionsMacpaul Lin
The dts file of the MediaTek MT8195 demo board has been updated to include new reserved memory regions. These reserved memory regions are: - SCP - VPU, - Sound DMA - APU. These regions are defined with the "shared-dma-pool" compatible property. In addition, the existing reserved memory regions have been reordered by their addresses to improve readability and maintainability of the DTS file. Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5 Fixes: e4a417520101 ("arm64: dts: mediatek: mt8195-demo: fix the memory size of node secmon") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230905034511.11232-2-macpaul.lin@mediatek.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-3-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-06arm64: dts: mediatek: mt8195-demo: fix the memory size to 8GBMacpaul Lin
The onboard dram of mt8195-demo board is 8GB. Cc: stable@vger.kernel.org # 6.1, 6.4, 6.5 Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board") Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230905034511.11232-1-macpaul.lin@mediatek.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-2-dad7cd62a8ff@collabora.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-06arch: Reserve map_shadow_stack() syscall number for all architecturesSohil Mehta
commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall") recently added support for map_shadow_stack() but it is limited to x86 only for now. There is a possibility that other architectures (namely, arm64 and RISC-V), that are implementing equivalent support for shadow stacks, might need to add support for it. Independent of that, reserving arch-specific syscall numbers in the syscall tables of all architectures is good practice and would help avoid future conflicts. map_shadow_stack() is marked as a conditional syscall in sys_ni.c. Adding it to the syscall tables of other architectures is harmless and would return ENOSYS when exercised. Note, map_shadow_stack() was assigned #453 during the merge process since #452 was taken by fchmodat2(). For Powerpc, map it to sys_ni_syscall() as is the norm for Powerpc syscall tables. For Alpha, map_shadow_stack() takes up #563 as Alpha still diverges from the common syscall numbering system in the other architectures. Link: https://lore.kernel.org/lkml/20230515212255.GA562920@debug.ba.rivosinc.com/ Link: https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b78a@sirena.org.uk/ Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-10-06sparc: Annotate struct cpuinfo_tree with __counted_byKees Cook
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct cpuinfo_tree. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175159.work.357-kees@kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2023-10-06x86/tdx: Mark TSC reliableKirill A. Shutemov
In x86 virtualization environments, including TDX, RDTSC instruction is handled without causing a VM exit, resulting in minimal overhead and jitters. On the other hand, other clock sources (such as HPET, ACPI timer, APIC, etc.) necessitate VM exits to implement, resulting in more fluctuating measurements compared to TSC. Thus, those clock sources are not effective for calibrating TSC. As a foundation, the host TSC is guaranteed to be invariant on any system which enumerates TDX support. TDX guests and the TDX module build on that foundation by enforcing: - Virtual TSC is monotonously incrementing for any single VCPU; - Virtual TSC values are consistent among all the TD’s VCPUs at the level supported by the CPU: + VMM is required to set the same TSC_ADJUST; + VMM must not modify from initial value of TSC_ADJUST before SEAMCALL; - The frequency is determined by TD configuration: + Virtual TSC frequency is specified by VMM on TDH.MNG.INIT; + Virtual TSC starts counting from 0 at TDH.MNG.INIT; The result is that a reliable TSC is a TDX architectural guarantee. Use the TSC as the only reliable clock source in TD guests, bypassing unstable calibration. This is similar to what the kernel already does in some VMWare and HyperV environments. [ dhansen: changelog tweaks ] Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Erdem Aktas <erdemaktas@google.com> Reviewed-by: Isaku Yamahata <isaku.yamahata@intel.com> Acked-by: Kai Huang <kai.huang@intel.com> Link: https://lore.kernel.org/all/20231006144549.2633-1-kirill.shutemov%40linux.intel.com
2023-10-06Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "A typo fix for a PMU driver, a workround for a side-channel erratum on Cortex-A520 and a fix for the local timer save/restore when using ACPI with Qualcomm's custom CPUs: - Workaround for Cortex-A520 erratum #2966298 - Fix typo in Arm CMN PMU driver that breaks counter overflow handling - Fix timer handling across idle for Qualcomm custom CPUs" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: cpuidle, ACPI: Evaluate LPI arch_flags for broadcast timer arm64: errata: Add Cortex-A520 speculative unprivileged load workaround arm64: Add Cortex-A520 CPU part definition perf/arm-cmn: Fix the unhandled overflow status of counter 4 to 7
2023-10-06arm64: dts: amlogic: add libretech cottonwood supportJerome Brunet
Add support for the Libretech cottonwood board family. These 2 boards are based on the same PCB, with an RPi B form factor. The "Alta" board uses an a311d while the "Solitude" variant uses an s905d3. Co-developed-by: Da Xue <da.xue@libretech.co> Signed-off-by: Da Xue <da.xue@libretech.co> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231006103500.2015183-3-jbrunet@baylibre.com [narmstrong: squashed blue/green led inversion fix] Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2023-10-06x86/PCI: Avoid PME from D3hot/D3cold for AMD Rembrandt and Phoenix USB4Mario Limonciello
Iain reports that USB devices can't be used to wake a Lenovo Z13 from suspend. This occurs because on some AMD platforms, even though the Root Ports advertise PME_Support for D3hot and D3cold, wakeup events from devices on a USB4 controller don't result in wakeup interrupts from the Root Port when amd-pmc has put the platform in a hardware sleep state. If amd-pmc will be involved in the suspend, remove D3hot and D3cold from the PME_Support mask of Root Ports above USB4 controllers so we avoid those states if we need wakeups. Restore D3 support at resume so that it can be used by runtime suspend. This affects both AMD Rembrandt and Phoenix SoCs. "pm_suspend_target_state == PM_SUSPEND_ON" means we're doing runtime suspend, and amd-pmc will not be involved. In that case PMEs work as advertised in D3hot/D3cold, so we don't need to do anything. Note that amd-pmc is technically optional, and there's no need for this quirk if it's not present, but we assume it's always present because power consumption is so high without it. Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") Link: https://lore.kernel.org/r/20231004144959.158840-1-mario.limonciello@amd.com Reported-by: Iain Lane <iain@orangesquash.org.uk> Closes: https://forums.lenovo.com/t5/Ubuntu/Z13-can-t-resume-from-suspend-with-external-USB-keyboard/m-p/5217121 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> [bhelgaas: commit log, move to arch/x86/pci/fixup.c, add #includes] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
2023-10-06powerpc/iommu: Do not do platform domain attach atctions after probeJason Gunthorpe
POWER throws a splat at boot, it looks like the DMA ops were probably changed while a driver was attached. Something is still weird about how power sequences its bootup. Previously this was hidden since the core iommu code did nothing during probe, now it calls spapr_tce_platform_iommu_attach_dev(). Make spapr_tce_platform_iommu_attach_dev() do nothing on the probe time call like it did before. WARNING: CPU: 0 PID: 8 at arch/powerpc/kernel/iommu.c:407 __iommu_free+0x1e4/0x1f0 Modules linked in: sd_mod t10_pi crc64_rocksoft crc64 sg ibmvfc mlx5_core(+) scsi_transport_fc ibmveth mlxfw psample dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.6.0-rc3-next-20230929-auto #1 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1030.30 (NH1030_062) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005f6d4 LR: c00000000005f6d0 CTR: 00000000005ca81c REGS: c000000003a27890 TRAP: 0700 Not tainted (6.6.0-rc3-next-20230929-auto) MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48000824 XER: 00000008 CFAR: c00000000020f738 IRQMASK: 0 GPR00: c00000000005f6d0 c000000003a27b30 c000000001481800 000000000000017 GPR04: 00000000ffff7fff c000000003a27950 c000000003a27948 0000000000000027 GPR08: c000000c18c07c10 0000000000000001 0000000000000027 c000000002ac8a08 GPR12: 0000000000000000 c000000002ff0000 c00000000019cc88 c000000003042300 GPR16: 0000000000000000 0000000000000000 0000000000000000 c000000003071ab0 GPR20: c00000000349f80d c000000003215440 c000000003215480 61c8864680b583eb GPR24: 0000000000000000 000000007fffffff 0800000020000000 0000000000000010 GPR28: 0000000000020000 0000800000020000 c00000000c5dc800 c00000000c5dc880 NIP [c00000000005f6d4] __iommu_free+0x1e4/0x1f0 LR [c00000000005f6d0] __iommu_free+0x1e0/0x1f0 Call Trace: [c000000003a27b30] [c00000000005f6d0] __iommu_free+0x1e0/0x1f0 (unreliable) [c000000003a27bc0] [c00000000005f848] iommu_free+0x28/0x70 [c000000003a27bf0] [c000000000061518] iommu_free_coherent+0x68/0xa0 [c000000003a27c20] [c00000000005e8d4] dma_iommu_free_coherent+0x24/0x40 [c000000003a27c40] [c00000000024698c] dma_free_attrs+0x10c/0x140 [c000000003a27c90] [c008000000dcb8d4] mlx5_cmd_cleanup+0x5c/0x90 [mlx5_core] [c000000003a27cc0] [c008000000dc45a0] mlx5_mdev_uninit+0xc8/0x100 [mlx5_core] [c000000003a27d00] [c008000000dc4ac4] probe_one+0x3ec/0x530 [mlx5_core] [c000000003a27d90] [c0000000008c5edc] local_pci_probe+0x6c/0x110 [c000000003a27e10] [c000000000189c98] work_for_cpu_fn+0x38/0x60 [c000000003a27e40] [c00000000018d1d0] process_scheduled_works+0x230/0x4f0 [c000000003a27f10] [c00000000018ff14] worker_thread+0x1e4/0x500 [c000000003a27f90] [c00000000019cdb8] kthread+0x138/0x140 [c000000003a27fe0] [c00000000000df98] start_kernel_thread+0x14/0x18 Code: 481b004d 60000000 e89e0028 3c62ffe0 3863dd20 481b0039 60000000 e89e0038 3c62ffe0 3863dd38 481b0025 60000000 <0fe00000> 4bffff20 60000000 3c4c0142 ---[ end trace 0000000000000000 ]--- iommu_free: invalid entry entry = 0x8000000203d0 dma_addr = 0x8000000203d0000 Table = 0xc00000000c5dc800 bus# = 0x1 size = 0x20000 startOff = 0x800000000000 index = 0x70200016 Fixes: 2ad56efa80db ("powerpc/iommu: Setup a default domain and remove set_platform_dma_ops") Reported-by: Tasmiya Nalatwad <tasmiya@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/d06cee81-c47f-9d62-dfc6-4c77b60058db@linux.vnet.ibm.com Tested-by: Tasmiya Nalatwad <tasmiya@linux.vnet.ibm.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/0-v1-2b52423411b9+164fc-iommu_ppc_defdomain_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
2023-10-06riscv: Add SOPHGO SOC family Kconfig supportChen Wang
The first SoC in the SOPHGO series is SG2042, which contains 64 RISC-V cores. Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Chao Wei <chao.wei@sophgo.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-10-06ARM: exynos_defconfig: add driver for ISL29018Marek Szyprowski
Intersil 29018 light and proximity sensor is built into Exynos based Peach-Pit/Pi Chromebooks, so enable driver for it to increase testing coverage. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20231006110631.3204334-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-10-06ARM: multi_v7_defconfig: add drivers for S5C73M3 & S5K6A3 camera sensorsMarek Szyprowski
Samsung S5C73M3 8Mp camera ISP and S5K6A3 RAW sensors are available on Exynos4412-based Midas family boards, so enable the driver for them to increase testing coverage. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20231006112106.3205618-1-m.szyprowski@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2023-10-06arm64: smp: Don't directly call arch_smp_send_reschedule() for wakeupDouglas Anderson
In commit 2b2d0a7a96ab ("arm64: smp: Remove dedicated wakeup IPI") we started using a scheduler IPI to avoid a dedicated reschedule. When we did this, we used arch_smp_send_reschedule() directly rather than calling smp_send_reschedule(). The only difference is that calling arch_smp_send_reschedule() directly avoids tracing. Presumably we _don't_ want to avoid tracing here, so switch to smp_send_reschedule(). Fixes: 2b2d0a7a96ab ("arm64: smp: Remove dedicated wakeup IPI") Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-10-06arm64: smp: avoid NMI IPIs with broken MediaTek FWMark Rutland
Some MediaTek devices have broken firmware which corrupts some GICR registers behind the back of the OS, and pseudo-NMIs cannot be used on these devices. For more details see commit: 44bd78dd2b8897f5 ("irqchip/gic-v3: Disable pseudo NMIs on Mediatek devices w/ firmware issues") We did not take this problem into account in commit: 331a1b3a836c0f38 ("arm64: smp: Add arch support for backtrace using pseudo-NMI") Since that commit arm64's SMP code will try to setup some IPIs as pseudo-NMIs, even on systems with broken FW. The GICv3 code will (rightly) reject attempts to request interrupts as pseudo-NMIs, resulting in boot-time failures. Avoid the problem by taking the broken FW into account when deciding to request IPIs as pseudo-NMIs. The GICv3 driver maintains a static_key named "supports_pseudo_nmis" which is false on systems with broken FW, and we can consult this within ipi_should_be_nmi(). Fixes: 331a1b3a836c ("arm64: smp: Add arch support for backtrace using pseudo-NMI") Reported-by: Chen-Yu Tsai <wenst@chromium.org> Closes: https://issuetracker.google.com/issues/197061987#comment68 Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2023-10-06arm64: dts: imx93: add the Flex-CAN stop mode by GPRHaibo Chen
imx93 A0 chip use the internal q-channel handshake signal in LPCG and CCM to automatically handle the Flex-CAN stop mode. But this method meet issue when do the system PM stress test. IC can't fix it easily. So in the new imx93 A1 chip, IC drop this method, and involve back the old way，use the GPR method to trigger the Flex-CAN stop mode signal. Now NXP claim to drop imx93 A0, and only support imx93 A1. So here add the stop mode through GPR. This patch also fix a typo for aonmix_ns_gpr. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://lore.kernel.org/all/20230726112458.3524165-1-haibo.chen@nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-10-06platform/x86/intel/ifs: Store IFS generation numberJithu Joseph
IFS generation number is reported via MSR_INTEGRITY_CAPS. As IFS support gets added to newer CPUs, some differences are expected during IFS image loading and test flows. Define MSR bitmasks to extract and store the generation in driver data, so that driver can modify its MSR interaction appropriately. Signed-off-by: Jithu Joseph <jithu.joseph@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Tested-by: Pengfei Xu <pengfei.xu@intel.com> Link: https://lore.kernel.org/r/20231005195137.3117166-2-jithu.joseph@intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2023-10-06arm64: dts: ti: Fix HDMI Audio overlay in MakefileAradhya Bhatia
Apply HDMI audio overlay to AM625 and AM62-LP SK-EVMs DT binaries, instead of leaving it in a floating state. Fixes: b50ccab9e07c ("arm64: dts: ti: am62x-sk: Add overlay for HDMI audio") Reported-by: Rob Herring <robh@kernel.org> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Link: https://lore.kernel.org/r/20231003092259.28103-1-a-bhatia1@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2023-10-06MIPS: Remove dead code in relocate_new_kernelTiezhu Yang
There are two adjacent "b" instructions, the second one is unreachable, it is dead code, just remove it. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-10-06mips: dts: ralink: mt7621: rename to GnuBee GB-PC1 and GnuBee GB-PC2Arınç ÜNAL
Rename GB-PC1 to GnuBee GB-PC1, and GB-PC2 to GnuBee GB-PC2 to include brand and model name. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-10-06mips: dts: ralink: mt7621: define each reset as an itemArınç ÜNAL
Each item of the resets property should define a reset. Split the item with two resets on the ethernet node into two separate items. Sort the items of the clocks property to the same line as a trivial change. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-10-06mips: dts: ingenic: Remove unneeded probe-type propertiesGeert Uytterhoeven
The "probe-type" property was only needed when used with the (long obsolete) "direct-mapped" compatible value. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-10-06MIPS: loongson32: Remove dma.h and nand.hKeguang Zhang
Since commit 7b3415f581c7 ("MIPS: Loongson32: Remove unused platform devices"), struct plat_ls1x_dma and plat_ls1x_nand are unused. Then, dma.h and nand.h are useless. Therefore, remove these useless header files. Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2023-10-06m68k: defconfig: Update virt_defconfig for v6.6-rc3Geert Uytterhoeven
- Enable CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE (no longer auto-enabled since commit bb6c4507fe825f1b ("drm: fix up fbdev Kconfig defaults")), - Drop CONFIG_FRAMEBUFFER_CONSOLE=y (auto-enabled since commit bb6c4507fe825f1b ("drm: fix up fbdev Kconfig defaults")). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/6f30b86b83b972e9902b62295f397a20512d5507.1695977960.git.geert@linux-m68k.org
2023-10-06m68k: defconfig: Update defconfigs for v6.6-rc1Geert Uytterhoeven
- Enable modular build of the new device model tests, - Enable modular build of the glob self-test on configs that didn't have it yet (visible since commit b67abaad4d25b5d9 ("kunit: Allow kunit test modules to use test filtering")), - Replace CONFIG_FB=y by CONFIG_FRAMEBUFFER_CONSOLE=y on the virt platform (the former is no longer needed since commit 55bffc8170bb5813 ("fbdev: Split frame buffer support in FB and FB_CORE symbols")), the latter is no longer auto-enabled since commit a5ae331edb02b664 ("drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION")). Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/43ef623c9053862d93fbc746689d4897b35597ef.1694442486.git.geert@linux-m68k.org
2023-10-06m68k: io: Mark mmio read addresses as constArnd Bergmann
Passing constant __iomem tokens into the readl() family of helpers or any of the others causes a warning on m68k: include/asm-generic/io.h: In function 'ioread8_rep': arch/m68k/include/asm/io_mm.h:375:44: warning: passing argument 1 of 'raw_insb' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 375 | #define readsb(port, buf, nr) raw_insb((port), (u8 Add a 'const' modifier to the pointers to shut up the warnings here. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309251926.bPl23AhG-lkp@intel.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20230925155328.443664-1-arnd@kernel.org [geert: Fix missed rom_in_{8,be16,le16}()] Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2023-10-06m68k: Replace GPL 2.0+ README.legal boilerplate with SPDXGeert Uytterhoeven
Upstream Linux never had a "README.legal" file, but it was present in early source releases of Linux/m68k. It contained a simple copyright notice and a link to a version of the "COPYING" file that predated the addition of the "only valid GPL version is v2" clause. Get rid of the references to non-existent files by replacing the boilerplate with SPDX license identifiers. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Link: https://lore.kernel.org/r/23430c233728ab02ec0af8e714994398d383137a.1695031668.git.geert@linux-m68k.org
2023-10-06m68k: sun3: Change led_pattern[] to unsigned charGeert Uytterhoeven
The values stored in led_pattern[] are only used for passing to sun3_leds(), which takes an "unsigned char". Change the type of led_pattern[] accordingly, to reduce kernel size. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/794c5d543dbdae8336a13ef2459adafaaadb7d86.1695031620.git.geert@linux-m68k.org
2023-10-06m68k: Add missing types to asm/irq.hRolf Eike Beer
As reported in commit f8b648bf6628 ("net: sunhme: move asm includes to below linux includes") when including this <asm/*> header before the needed <linux/*> headers the compilation will fail because of missing types: arch/m68k/include/asm/irq.h:66:20: warning: ‘struct pt_regs’ declared inside parameter list will not be visible outside of this definition or declaration 66 | struct pt_regs *)); | ^~~~~~~ arch/m68k/include/asm/irq.h:78:11: error: expected ‘;’ before ‘void’ 78 | asmlinkage void do_IRQ(int irq, struct pt_regs *regs); | ^~~~~ | ; arch/m68k/include/asm/irq.h:78:40: warning: ‘struct pt_regs’ declared inside parameter list will not be visible outside of this definition or declaration 78 | asmlinkage void do_IRQ(int irq, struct pt_regs *regs); | ^~~~~~~ arch/m68k/include/asm/irq.h:79:8: error: unknown type name ‘atomic_t’ 79 | extern atomic_t irq_err_count; | ^~~~~~~~ Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/5971770.lOV4Wx5bFT@eto.sf-tec.de Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
generated by cgit (git 2.34.1) at 2025-10-01 15:00:50 +0000