summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2024-06-11MIPS: Alchemy: Switch to use kmemdup_array()Andy Shevchenko
Let the kememdup_array() take care about multiplication and possible overflows. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2024-06-11x86/sev: Use kernel provided SVSM Calling AreasTom Lendacky
The SVSM Calling Area (CA) is used to communicate between Linux and the SVSM. Since the firmware supplied CA for the BSP is likely to be in reserved memory, switch off that CA to a kernel provided CA so that access and use of the CA is available during boot. The CA switch is done using the SVSM core protocol SVSM_CORE_REMAP_CA call. An SVSM call is executed by filling out the SVSM CA and setting the proper register state as documented by the SVSM protocol. The SVSM is invoked by by requesting the hypervisor to run VMPL0. Once it is safe to allocate/reserve memory, allocate a CA for each CPU. After allocating the new CAs, the BSP will switch from the boot CA to the per-CPU CA. The CA for an AP is identified to the SVSM when creating the VMSA in preparation for booting the AP. [ bp: Heavily simplify svsm_issue_call() asm, other touchups. ] Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/fa8021130bcc3bcf14d722a25548cb0cdf325456.1717600736.git.thomas.lendacky@amd.com
2024-06-11x86/sev: Check for the presence of an SVSM in the SNP secrets pageTom Lendacky
During early boot phases, check for the presence of an SVSM when running as an SEV-SNP guest. An SVSM is present if not running at VMPL0 and the 64-bit value at offset 0x148 into the secrets page is non-zero. If an SVSM is present, save the SVSM Calling Area address (CAA), located at offset 0x150 into the secrets page, and set the VMPL level of the guest, which should be non-zero, to indicate the presence of an SVSM. [ bp: Touchups. ] Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/9d3fe161be93d4ea60f43c2a3f2c311fe708b63b.1717600736.git.thomas.lendacky@amd.com
2024-06-11x86/irqflags: Provide native versions of the local_irq_save()/restore()Tom Lendacky
Functions that need to disable IRQs, but are common to both early boot and post-boot execution, are unable to deal with paravirt support associated with local_irq_save() and local_irq_restore(). Create native versions of these for use in these situations. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/c4c33c0d07200164a3dd8cfd6da0344f57732648.1717600736.git.thomas.lendacky@amd.com
2024-06-10Merge tag 'for-netdev' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2024-06-06 We've added 54 non-merge commits during the last 10 day(s) which contain a total of 50 files changed, 1887 insertions(+), 527 deletions(-). The main changes are: 1) Add a user space notification mechanism via epoll when a struct_ops object is getting detached/unregistered, from Kui-Feng Lee. 2) Big batch of BPF selftest refactoring for sockmap and BPF congctl tests, from Geliang Tang. 3) Add BTF field (type and string fields, right now) iterator support to libbpf instead of using existing callback-based approaches, from Andrii Nakryiko. 4) Extend BPF selftests for the latter with a new btf_field_iter selftest, from Alan Maguire. 5) Add new kfuncs for a generic, open-coded bits iterator, from Yafang Shao. 6) Fix BPF selftests' kallsyms_find() helper under kernels configured with CONFIG_LTO_CLANG_THIN, from Yonghong Song. 7) Remove a bunch of unused structs in BPF selftests, from David Alan Gilbert. 8) Convert test_sockmap section names into names understood by libbpf so it can deduce program type and attach type, from Jakub Sitnicki. 9) Extend libbpf with the ability to configure log verbosity via LIBBPF_LOG_LEVEL environment variable, from Mykyta Yatsenko. 10) Fix BPF selftests with regards to bpf_cookie and find_vma flakiness in nested VMs, from Song Liu. 11) Extend riscv32/64 JITs to introduce shift/add helpers to generate Zba optimization, from Xiao Wang. 12) Enable BPF programs to declare arrays and struct fields with kptr, bpf_rb_root, and bpf_list_head, from Kui-Feng Lee. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (54 commits) selftests/bpf: Drop useless arguments of do_test in bpf_tcp_ca selftests/bpf: Use start_test in test_dctcp in bpf_tcp_ca selftests/bpf: Use start_test in test_dctcp_fallback in bpf_tcp_ca selftests/bpf: Add start_test helper in bpf_tcp_ca selftests/bpf: Use connect_to_fd_opts in do_test in bpf_tcp_ca libbpf: Auto-attach struct_ops BPF maps in BPF skeleton selftests/bpf: Add btf_field_iter selftests selftests/bpf: Fix send_signal test with nested CONFIG_PARAVIRT libbpf: Remove callback-based type/string BTF field visitor helpers bpftool: Use BTF field iterator in btfgen libbpf: Make use of BTF field iterator in BTF handling code libbpf: Make use of BTF field iterator in BPF linker code libbpf: Add BTF field iterator selftests/bpf: Ignore .llvm.<hash> suffix in kallsyms_find() selftests/bpf: Fix bpf_cookie and find_vma in nested VM selftests/bpf: Test global bpf_list_head arrays. selftests/bpf: Test global bpf_rb_root arrays and fields in nested struct types. selftests/bpf: Test kptr arrays and kptrs in nested struct fields. bpf: limit the number of levels of a nested struct type. bpf: look into the types of the fields of a struct type recursively. ... ==================== Link: https://lore.kernel.org/r/20240606223146.23020-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-06-10KVM: x86: Bury guest_cpuid_is_amd_or_hygon() in cpuid.cSean Christopherson
Move guest_cpuid_is_amd_or_hygon() into cpuid.c now that, except for one Intel quirk in the emulator, KVM checks for AMD vs. Intel *compatible* vCPUs, not exact vendors, i.e. now that there should not be any reason for KVM at-large to care about the exact vendor. Opportunistically refactor the guts of the helper to use "entry" instead of "best", and short circuit the !entry path to make the common case more readable. Link: https://lore.kernel.org/r/20240405235603.1173076-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86: Open code vendor_intel() in string_registers_quirk()Sean Christopherson
Open code the is_guest_vendor_intel() check in string_registers_quirk() to discourage makiking exact vendor==Intel checks in the emulator, and to remove the rather awful #ifdeffery. The string quirk is literally the only Intel specific, *non-architectural* behavior that KVM emulates. All Intel specific behavior that is architecturally defined applies to all vendors that are compatible with Intel's architecture, i.e. should use guest_cpuid_is_intel_compatible(). Link: https://lore.kernel.org/r/20240405235603.1173076-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86: Allow SYSENTER in Compatibility Mode for all Intel compat vCPUsSean Christopherson
Emulate SYSENTER in Compatibility Mode for all vCPUs models that are compatible with Intel's architecture, as the behavior if SYSENTER is architecturally defined in Intel's SDM, i.e. should be followed by any CPU that implements Intel's architecture. Link: https://lore.kernel.org/r/20240405235603.1173076-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: SVM: Emulate SYSENTER RIP/RSP behavior for all Intel compat vCPUsSean Christopherson
Emulate bits 63:32 of the SYSENTER_R{I,S}P MSRs for all vCPUs that are compatible with Intel's architecture, not just strictly vCPUs that have vendor==Intel. The behavior of bits 63:32 is architecturally defined in the SDM, i.e. not some uarch specific quirk of Intel CPUs. Link: https://lore.kernel.org/r/20240405235603.1173076-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86: Use "is Intel compatible" helper to emulate SYSCALL in !64-bitSean Christopherson
Use guest_cpuid_is_intel_compatible() to determine whether SYSCALL in 32-bit Protected Mode (including Compatibility Mode) should #UD or succeed. The existing code already does the exact equivalent of guest_cpuid_is_intel_compatible(), just in a rather roundabout way. No functional change intended. Link: https://lore.kernel.org/r/20240405235603.1173076-7-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86: Inhibit code #DBs in MOV-SS shadow for all Intel compat vCPUsSean Christopherson
Treat code #DBs as inhibited in MOV/POP-SS shadows for vCPU models that are Intel compatible, not just strictly vCPUs with vendor==Intel. The behavior is explicitly called out in the SDM, and thus architectural, i.e. applies to all CPUs that implement Intel's architecture, and isn't a quirk that is unique to CPUs manufactured by Intel: However, if an instruction breakpoint is placed on an instruction located immediately after a POP SS/MOV SS instruction, the breakpoint will be suppressed as if EFLAGS.RF were 1. Applying the behavior strictly to Intel wasn't intentional, KVM simply didn't have a concept of "Intel compatible" as of commit baf67ca8e545 ("KVM: x86: Suppress code #DBs on Intel if MOV/POP SS blocking is active"). Link: https://lore.kernel.org/r/20240405235603.1173076-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86: Apply Intel's TSC_AUX reserved-bit behavior to Intel compat vCPUsSean Christopherson
Extend Intel's check on MSR_TSC_AUX[63:32] to all vCPU models that are Intel compatible, i.e. aren't AMD or Hygon in KVM's world, as the behavior is architectural, i.e. applies to any CPU that is compatible with Intel's architecture. Applying the behavior strictly to Intel wasn't intentional, KVM simply didn't have a concept of "Intel compatible" as of commit 61a05d444d2c ("KVM: x86: Tie Intel and AMD behavior for MSR_TSC_AUX to guest CPU model"). Link: https://lore.kernel.org/r/20240405235603.1173076-5-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86/pmu: Squash period for checkpointed events based on host HLE/RTMSean Christopherson
Zero out the sampling period for checkpointed events if the host supports HLE or RTM, i.e. supports transactions and thus checkpointed events, not based on whether the vCPU vendor model is Intel. Perf's refusal to allow a sample period for checkpointed events is based purely on whether or not the CPU supports HLE/RTM transactions, i.e. perf has no knowledge of the vCPU vendor model. Note, it is _extremely_ unlikely that the existing code is a problem in real world usage, as there are far, far bigger hurdles that would need to be cleared to support cross-vendor vPMUs. The motivation is mainly to eliminate the use of guest_cpuid_is_intel(), in order to get to a state where KVM pivots on AMD vs. Intel compatibility, i.e. doesn't check for exactly vendor==Intel except in rare circumstances (i.e. for CPU quirks). Cc: Like Xu <like.xu.linux@gmail.com> Link: https://lore.kernel.org/r/20240405235603.1173076-4-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: VMX: Remove unused declaration of vmx_request_immediate_exit()Binbin Wu
After commit 0ec3d6d1f169 "KVM: x86: Fully defer to vendor code to decide how to force immediate exit", vmx_request_immediate_exit() was removed. Commit 5f18c642ff7e "KVM: VMX: Move out vmx_x86_ops to 'main.c' to dispatch VMX and TDX" added its declaration by accident. Remove it. Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> Link: https://lore.kernel.org/r/20240506075025.2251131-1-binbin.wu@linux.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10KVM: x86: Drop unused check_apicv_inhibit_reasons() callback definitionHou Wenlong
The check_apicv_inhibit_reasons() callback implementation was dropped in the commit b3f257a84696 ("KVM: x86: Track required APICv inhibits with variable, not callback"), but the definition removal was missed in the final version patch (it was removed in the v4). Therefore, it should be dropped, and the vmx_check_apicv_inhibit_reasons() function declaration should also be removed. Signed-off-by: Hou Wenlong <houwenlong.hwl@antgroup.com> Reviewed-by: Alejandro Jimenez <alejandro.j.jimenez@oracle.com> Link: https://lore.kernel.org/r/54abd1d0ccaba4d532f81df61259b9c0e021fbde.1714977229.git.houwenlong.hwl@antgroup.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2024-06-10ARM: 9404/1: arm32: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATIONYuntao Liu
The current arm32 architecture does not yet support the HAVE_LD_DEAD_CODE_DATA_ELIMINATION feature. arm32 is widely used in embedded scenarios, and enabling this feature would be beneficial for reducing the size of the kernel image. In order to make this work, we keep the necessary tables by annotating them with KEEP, also it requires further changes to linker script to KEEP some tables and wildcard compiler generated sections into the right place. When using ld.lld for linking, KEEP is not recognized within the OVERLAY command, and Ard proposed a concise method to solve this problem. It boots normally with defconfig, vexpress_defconfig and tinyconfig. The size comparison of zImage is as follows: defconfig vexpress_defconfig tinyconfig 5137712 5138024 424192 no dce 5032560 4997824 298384 dce 2.0% 2.7% 29.7% shrink When using smaller config file, there is a significant reduction in the size of the zImage. We also tested this patch on a commercially available single-board computer, and the comparison is as follows: a15eb_config 2161384 no dce 2092240 dce 3.2% shrink The zImage size has been reduced by approximately 3.2%, which is 70KB on 2.1M. Signed-off-by: Yuntao Liu <liuyuntao12@huawei.com> Tested-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9403/1: Alpine: Spelling s/initialiing/initializing/Geert Uytterhoeven
Fix a misspelling of "initializing". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9402/1: Kconfig: Spelling s/Cortex A-/Cortex-A/Geert Uytterhoeven
Fix a misspelling of "Cortex-A9", to make it easier to find which errata are applicable to Cortex-A9 CPU cores. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9400/1: Remove unused struct 'mod_unwind_map'Dr. David Alan Gilbert
I think this has been unused since Commit b6f21d14f1ac ("ARM: 9204/2: module: Add all unwind tables when load module") Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10ARM: 9405/1: ftrace: Don't assume stack frames are contiguous in memoryArd Biesheuvel
The frame pointer unwinder relies on a standard layout of the stack frame, consisting of (in downward order) Calling frame: PC <---------+ LR | SP | FP | .. locals .. | Callee frame: | PC | LR | SP | FP ----------+ where after storing its previous value on the stack, FP is made to point at the location of PC in the callee stack frame, using the canonical prologue: mov ip, sp stmdb sp!, {fp, ip, lr, pc} sub fp, ip, #4 The ftrace code assumes that this activation record is pushed first, and that any stack space for locals is allocated below this. Strict adherence to this would imply that the caller's value of SP at the time of the function call can always be obtained by adding 4 to FP (which points to PC in the callee frame). However, recent versions of GCC appear to deviate from this rule, and so the only reliable way to obtain the caller's value of SP is to read it from the activation record. Since this involves a read from memory rather than simple arithmetic, we need to use the uaccess API here which protects against inadvertent data aborts resulting from attempts to dereference bogus FP values. The plain uaccess API is ftrace instrumented itself, so to avoid unbounded recursion, use the __get_kernel_nofault() primitive directly. Closes: https://lore.kernel.org/all/alp44tukzo6mvcwl4ke4ehhmojrqnv6xfcdeuliybxfjfvgd3e@gpjvwj33cc76 Closes: https://lore.kernel.org/all/d870c149-4363-43de-b0ea-7125dec5608e@broadcom.com/ Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reported-by: Justin Chen <justin.chen@broadcom.com> Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2024-06-10x86/resctrl: Replace open coded cacheinfo searchesTony Luck
pseudo_lock_region_init() and rdtgroup_cbm_to_size() open code a search for details of a particular cache level. Replace with get_cpu_cacheinfo_level(). Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Link: https://lore.kernel.org/r/20240610003927.341707-5-tony.luck@intel.com
2024-06-09ARM: configs: at91: Enable LVDS serializer supportDharma Balasubiramani
Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> Acked-by: Hari Prasath Gujulan Elango <hari.prasathge@microchip.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20240421011050.43265-5-dharma.b@microchip.com Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2024-06-08Merge tag 'x86-urgent-2024-06-08' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Miscellaneous fixes: - Fix kexec() crash if call depth tracking is enabled - Fix SMN reads on inaccessible registers on certain AMD systems" * tag 'x86-urgent-2024-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/amd_nb: Check for invalid SMN reads x86/kexec: Fix bug with call depth tracking
2024-06-08arm64: dts: rockchip: set correct pwm0 pinctrl on rk3588-tigerHeiko Stuebner
PWM0 on rk3588-tiger is connected to the BLT_CTRL pin of the Q7 connector meant as the name implies to control a backlight device. Therefore set the correct M1 pinctrl variant for it. The M0 variant cannot ever be used because that pin is routed to a connector pin on the Q7 connector that is reserved for CAN use and the pin reachable by the M2 variant is reserved for the embedded MCU on the SoM. Fixes: 6173ef24b35b ("arm64: dts: rockchip: add RK3588-Q7 (Tiger) SoM") Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20240603192254.2441025-1-heiko@sntech.de Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-06-07Merge tag 'mm-hotfixes-stable-2024-06-07-15-24' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "14 hotfixes, 6 of which are cc:stable. All except the nilfs2 fix affect MM and all are singletons - see the chagelogs for details" * tag 'mm-hotfixes-stable-2024-06-07-15-24' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors mm: fix xyz_noprof functions calling profiled functions codetag: avoid race at alloc_slab_obj_exts mm/hugetlb: do not call vma_add_reservation upon ENOMEM mm/ksm: fix ksm_zero_pages accounting mm/ksm: fix ksm_pages_scanned accounting kmsan: do not wipe out origin when doing partial unpoisoning vmalloc: check CONFIG_EXECMEM in is_vmalloc_or_module_addr() mm: page_alloc: fix highatomic typing in multi-block buddies nilfs2: fix potential kernel bug due to lack of writeback flag waiting memcg: remove the lockdep assert from __mod_objcg_mlstate() mm: arm64: fix the out-of-bounds issue in contpte_clear_young_dirty_ptes mm: huge_mm: fix undefined reference to `mthp_stats' for CONFIG_SYSFS=n mm: drop the 'anon_' prefix for swap-out mTHP counters
2024-06-07arm64: dts: qcom: sm8650: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Also, register the GPU as a cooling device and hook it up to the right thermal zones. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-12-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8550: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Remove the copypasta-from-downstream userspace governor entries while at it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-11-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8450: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Remove the copypasta-from-downstream userspace governor entries while at it. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-10-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8350: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-9-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8250: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-8-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8150: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-7-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm6350: Update GPU thermal zone settingsKonrad Dybcio
Lower the thresholds to something more reasonable and introduce a passive polling delay to make sure more than one "passive" thermal point is taken into account when throttling. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-6-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm6115: Update GPU thermal zone settingsKonrad Dybcio
Lower the thresholds to something more reasonable and introduce a passive polling delay to make sure more than one "passive" thermal point is taken into account when throttling. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-5-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sdm845: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-4-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sdm630: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-3-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sc8280xp: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point with 1C of hysteresis to ensure the thermal framework takes sufficient action to prevent reaching junction temperature. Also, add passive polling to ensure more than one temperature change event is recorded. Fixes: 014bbc990e27 ("arm64: dts: qcom: sc8280xp: Introduce additional tsens instances") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-2-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sc8180x: Throttle the GPU when overheatingKonrad Dybcio
Add an 85C passive trip point to ensure the thermal framework takes sufficient action to prevent reaching junction temperature and a 110C critical point to help avoid hw damage. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-gpus_are_cool_now-v1-1-ababc269a438@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8650-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-31-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8550-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-30-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8450-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-29-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8350-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-28-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8250-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-27-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm8150-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-26-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm6375-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-25-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm6350-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-24-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm6125-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-23-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sm6115-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-22-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sdm845-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-21-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sdm660-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-20-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-06-07arm64: dts: qcom: sc8280xp-*: Remove thermal zone polling delaysKonrad Dybcio
All of the thermal zone suppliers are interrupt-driven, remove the bogus and unnecessary polling that only wastes CPU time. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240510-topic-msm-polling-cleanup-v2-19-436ca4218da2@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>