summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2025-02-22Merge tag 'x86-urgent-2025-02-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: - Fix AVX-VNNI CPU feature dependency bug triggered via the 'noxsave' boot option - Fix typos in the SVA documentation - Add Tony Luck as RDT co-maintainer and remove Fenghua Yu * tag 'x86-urgent-2025-02-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: docs: arch/x86/sva: Fix two grammar errors under Background and FAQ x86/cpufeatures: Make AVX-VNNI depend on AVX MAINTAINERS: Change maintainer for RDT
2025-02-22Merge tag 'perf-urgent-2025-02-22' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf event fixes from Ingo Molnar: "Fix x86 Intel Lion Cove CPU event constraints, and fix uprobes debug/error printk output pointer-value verbosity" * tag 'perf-urgent-2025-02-22' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Fix event constraints for LNC uprobes: Don't use %pK through printk
2025-02-22Merge tag 's390-6.14-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Fix inline asm constraint in cmma_test_essa() to avoid potential ESSA detection miscompilation - Fix build failure with CONFIG_GENDWARFKSYMS by disabling purgatory symbol exports with -D__DISABLE_EXPORTS - Update defconfigs * tag 's390-6.14-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/boot: Fix ESSA detection s390/purgatory: Use -D__DISABLE_EXPORTS s390: Update defconfigs
2025-02-22arm64: dts: allwinner: a100: Add CPU Operating Performance Points tableShuosheng Huang
Add an Operating Performance Points table for the CPU cores to enable Dynamic Voltage & Frequency Scaling on the A100. Signed-off-by: Shuosheng Huang <huangshuosheng@allwinnertech.com> [masterr3c0rd@epochal.quest: fix typos in -cpu-opp, use compatible] Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Link: https://patch.msgid.link/20241031070232.1793078-14-masterr3c0rd@epochal.quest Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-02-22arm64: dts: allwinner: rg35xx: Add no-thermistor property for batteryChris Morgan
Add the property of x-powers,no-thermistor for the battery of the Anbernic RG35XX series of H700 devices. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20250204155835.161973-5-macroalpha82@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-02-22arm64: dts: allwinner: h700: Add USB Host for RG35XX-HChris Morgan
The RG35XX-H has a USB host port in addition to the USB OTG port used for charging. The host port receives its power from two distinct GPIO controlled regulators. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20241018160617.157083-5-macroalpha82@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-02-22arm64: dts: allwinner: h700: Add LED1 for Anbernic RG35XXChris Morgan
Add the second LED (red) to the Anbernic RG35XX series. The RG35XX has 3 LEDs: an orange one that is controlled directly by the PMIC; and a green and red one that are controlled by GPIOs. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20241018160617.157083-4-macroalpha82@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-02-22arm64: dts: allwinner: h700: Set cpusldo to always-on for RG35XXChris Morgan
Set the cpusldo regulator for the AXP717 to "regulator-always-on". Its current functionality is still unknown as there are no schematics available, however it was observed that upon reboot if this regulator was disabled GPIO detection logic in the bootloader was inconsistent. Keep the regulator powered on for now until it can be defined correctly. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20241018160617.157083-3-macroalpha82@gmail.com Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-02-22perf/x86/intel/bts: Allocate bts_ctx only if necessaryLi RongQing
Avoid unnecessary per-CPU memory allocation on unsupported CPUs, this can save 12K memory for each CPU Signed-off-by: Li RongQing <lirongqing@baidu.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Kan Liang <kan.liang@linux.intel.com> Link: https://lore.kernel.org/r/20250122074103.3091-1-lirongqing@baidu.com
2025-02-22x86/cpu: Update Intel Family commentsPeter Zijlstra
Because who can ever remember all these names. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250127162252.GK16742@noisy.programming.kicks-ass.net
2025-02-22x86/kexec: Export e820_table_kexec[] to sysfsDave Young
Previously the e820_table_kexec[] was exported to sysfs since kexec-tools uses the memmap entries to prepare the e820 table for the new kernel. The following commit, ~8 years ago, introduced e820_table_firmware[] and changed the behavior to export the firmware table instead: 12df216c61c8 ("x86/boot/e820: Introduce the bootloader provided e820_table_firmware[] table") Originally the kexec_file_load and kexec_load syscalls both used e820_table_kexec[]. Since the sysfs exported entries are from e820_table_firmware[] people now need to tune both tables for kexec. Restore the old behavior so the kexec_load and kexec_file_load syscalls work with only one table update. The e820_table_firmware[] is used by hibernation kernel code and it works without the sysfs exporting. Also remove the SEV e820_table_firmware[] updating code. Also update the code comments here and drop the comments about setup_data reservation since it is not needed any more after this change was made a year ago: fc7f27cda843 ("x86/kexec: Do not update E820 kexec table for setup_data") [ mingo: Tidy up the changelog and comments. ] Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Ashish Kalra <ashish.kalra@amd.com> Cc: Sean Christopherson <seanjc@google.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Baoquan He <bhe@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Eric Biederman <ebiederm@xmission.com> Link: https://lore.kernel.org/r/Z5jcb1GKhLvH8kDc@darkstar.users.ipa.redhat.com
2025-02-22x86/boot: Change some static bootflag functions to boolUros Bizjak
The return values of some functions are of boolean type. Change the type of these function to bool and adjust their return values. No functional change intended. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250129154920.6773-1-ubizjak@gmail.com
2025-02-22x86/kaslr: Reduce KASLR entropy on most x86 systemsBalbir Singh
When CONFIG_PCI_P2PDMA=y (which is basically enabled on all large x86 distros), it maps the PFN's via a ZONE_DEVICE mapping using devm_memremap_pages(). The mapped virtual address range corresponds to the pci_resource_start() of the BAR address and size corresponding to the BAR length. When KASLR is enabled, the direct map range of the kernel is reduced to the size of physical memory plus additional padding. If the BAR address is beyond this limit, PCI peer to peer DMA mappings fail. Fix this by not shrinking the size of the direct map when CONFIG_PCI_P2PDMA=y. This reduces the total available entropy, but it's better than the current work around of having to disable KASLR completely. [ mingo: Clarified the changelog to point out the broad impact ... ] Signed-off-by: Balbir Singh <balbirs@nvidia.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/Kconfig Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Link: https://lore.kernel.org/lkml/20250206023201.1481957-1-balbirs@nvidia.com/ Link: https://lore.kernel.org/r/20250206234234.1912585-1-balbirs@nvidia.com -- arch/x86/mm/kaslr.c | 10 ++++++++-- drivers/pci/Kconfig | 6 ++++++ 2 files changed, 14 insertions(+), 2 deletions(-)
2025-02-22x86/microcode/AMD: Load only SHA256-checksummed patchesBorislav Petkov (AMD)
Load patches for which the driver carries a SHA256 checksum of the patch blob. This can be disabled by adding "microcode.amd_sha_check=off" on the kernel cmdline. But it is highly NOT recommended. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
2025-02-22ARM: dts: mba6ul: change sound card model nameMarkus Niebel
The card name for ALSA is generated from the model name string and is limited to 16 characters. Use a shorter name to prevent cutting the name. Since nearly all starter kit mainboards for i.MX based SoM by TQ-Systems use the same codec with the same routing on board it is a good idea to use the same mode name for the sound card. This allows sharing a default asound.conf in BSP over all the kits. Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-02-22ARM: dts: imx7-mba7: change sound card model nameMarkus Niebel
The card name for ALSA is generated from the model name string and is limited to 16 characters. Use a shorter name to prevent cutting the name. Since nearly all starter kit mainboards for i.MX based SoM by TQ-Systems use the same codec with the same routing on board it is a good idea to use the same mode name for the sound card. This allows sharing a default asound.conf in BSP over all the kits. Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-02-22ARM: dts: imx6qdl-mba6: change sound card model nameMarkus Niebel
The card name for ALSA is generated from the model name string and is limited to 16 characters. Use a shorter name to prevent cutting the name. Since nearly all starter kit mainboards for i.MX based SoM by TQ-Systems use the same codec with the same routing on board it is a good idea to use the same mode name for the sound card. This allows sharing a default asound.conf in BSP over all the kits. Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-02-22crypto: x86/ghash - Use proper helpers to clone requestHerbert Xu
Rather than copying a request by hand with memcpy, use the correct API helpers to setup the new request. This will matter once the API helpers start setting up chained requests as a simple memcpy will break chaining. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-02-22crypto: lib/Kconfig - Fix lib built-in failure when arch is modularHerbert Xu
The HAVE_ARCH Kconfig options in lib/crypto try to solve the modular versus built-in problem, but it still fails when the the LIB option (e.g., CRYPTO_LIB_CURVE25519) is selected externally. Fix this by introducing a level of indirection with ARCH_MAY_HAVE Kconfig options, these then go on to select the ARCH_HAVE options if the ARCH Kconfig options matches that of the LIB option. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202501230223.ikroNDr1-lkp@intel.com/ Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-02-22crypto: x86/aes-xts - change license to Apache-2.0 OR BSD-2-ClauseEric Biggers
As with the other AES modes I've implemented, I've received interest in my AES-XTS assembly code being reused in other projects. Therefore, change the license to Apache-2.0 OR BSD-2-Clause like what I used for AES-GCM. Apache-2.0 is the license of OpenSSL and BoringSSL. Note that it is difficult to *directly* share code between the kernel, OpenSSL, and BoringSSL for various reasons such as perlasm vs. plain asm, Windows ABI support, different divisions of responsibility between C and asm in each project, etc. So whether that will happen instead of just doing ports is still TBD. But this dual license should at least make it possible to port changes between the projects. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-02-22crypto: x86/aes-ctr - rewrite AESNI+AVX optimized CTR and add VAES supportEric Biggers
Delete aes_ctrby8_avx-x86_64.S and add a new assembly file aes-ctr-avx-x86_64.S which follows a similar approach to aes-xts-avx-x86_64.S in that it uses a "template" to provide AESNI+AVX, VAES+AVX2, VAES+AVX10/256, and VAES+AVX10/512 code, instead of just AESNI+AVX. Wire it up to the crypto API accordingly. This greatly improves the performance of AES-CTR and AES-XCTR on VAES-capable CPUs, with the best case being AMD Zen 5 where an over 230% increase in throughput is seen on long messages. Performance on non-VAES-capable CPUs remains about the same, and the non-AVX AES-CTR code (aesni_ctr_enc) is also kept as-is for now. There are some slight regressions (less than 10%) on some short message lengths on some CPUs; these are difficult to avoid, given how the previous code was so heavily unrolled by message length, and they are not particularly important. Detailed performance results are given in the tables below. Both CTR and XCTR support is retained. The main loop remains 8-vector-wide, which differs from the 4-vector-wide main loops that are used in the XTS and GCM code. A wider loop is appropriate for CTR and XCTR since they have fewer other instructions (such as vpclmulqdq) to interleave with the AES instructions. Similar to what was the case for AES-GCM, the new assembly code also has a much smaller binary size, as it fixes the excessive unrolling by data length and key length present in the old code. Specifically, the new assembly file compiles to about 9 KB of text vs. 28 KB for the old file. This is despite 4x as many implementations being included. The tables below show the detailed performance results. The tables show percentage improvement in single-threaded throughput for repeated encryption of the given message length; an increase from 6000 MB/s to 12000 MB/s would be listed as 100%. They were collected by directly measuring the Linux crypto API performance using a custom kernel module. The tested CPUs were all server processors from Google Compute Engine except for Zen 5 which was a Ryzen 9 9950X desktop processor. Table 1: AES-256-CTR throughput improvement, CPU microarchitecture vs. message length in bytes: | 16384 | 4096 | 4095 | 1420 | 512 | 500 | ---------------------+-------+-------+-------+-------+-------+-------+ AMD Zen 5 | 232% | 203% | 212% | 143% | 71% | 95% | Intel Emerald Rapids | 116% | 116% | 117% | 91% | 78% | 79% | Intel Ice Lake | 109% | 103% | 107% | 81% | 54% | 56% | AMD Zen 4 | 109% | 91% | 100% | 70% | 43% | 59% | AMD Zen 3 | 92% | 78% | 87% | 57% | 32% | 43% | AMD Zen 2 | 9% | 8% | 14% | 12% | 8% | 21% | Intel Skylake | 7% | 7% | 8% | 5% | 3% | 8% | | 300 | 200 | 64 | 63 | 16 | ---------------------+-------+-------+-------+-------+-------+ AMD Zen 5 | 57% | 39% | -9% | 7% | -7% | Intel Emerald Rapids | 37% | 42% | -0% | 13% | -8% | Intel Ice Lake | 39% | 30% | -1% | 14% | -9% | AMD Zen 4 | 42% | 38% | -0% | 18% | -3% | AMD Zen 3 | 38% | 35% | 6% | 31% | 5% | AMD Zen 2 | 24% | 23% | 5% | 30% | 3% | Intel Skylake | 9% | 1% | -4% | 10% | -7% | Table 2: AES-256-XCTR throughput improvement, CPU microarchitecture vs. message length in bytes: | 16384 | 4096 | 4095 | 1420 | 512 | 500 | ---------------------+-------+-------+-------+-------+-------+-------+ AMD Zen 5 | 240% | 201% | 216% | 151% | 75% | 108% | Intel Emerald Rapids | 100% | 99% | 102% | 91% | 94% | 104% | Intel Ice Lake | 93% | 89% | 92% | 74% | 50% | 64% | AMD Zen 4 | 86% | 75% | 83% | 60% | 41% | 52% | AMD Zen 3 | 73% | 63% | 69% | 45% | 21% | 33% | AMD Zen 2 | -2% | -2% | 2% | 3% | -1% | 11% | Intel Skylake | -1% | -1% | 1% | 2% | -1% | 9% | | 300 | 200 | 64 | 63 | 16 | ---------------------+-------+-------+-------+-------+-------+ AMD Zen 5 | 78% | 56% | -4% | 38% | -2% | Intel Emerald Rapids | 61% | 55% | 4% | 32% | -5% | Intel Ice Lake | 57% | 42% | 3% | 44% | -4% | AMD Zen 4 | 35% | 28% | -1% | 17% | -3% | AMD Zen 3 | 26% | 23% | -3% | 11% | -6% | AMD Zen 2 | 13% | 24% | -1% | 14% | -3% | Intel Skylake | 16% | 8% | -4% | 35% | -3% | Signed-off-by: Eric Biggers <ebiggers@google.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-02-21arm64: dts: qcom: qcs8300-ride: Enable PMIC peripheralsTingguo Cheng
Enable PMIC and PMIC peripherals for qcs8300-ride board. The qcs8 300-ride uses 2 pmics(pmm8620au:0,pmm8650au:1) on the board, which are variants of pmm8654au used on sa8775p/qcs9100 -ride(4x pmics). Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Tingguo Cheng <quic_tingguoc@quicinc.com> Link: https://lore.kernel.org/r/20250108-adds-spmi-pmic-peripherals-for-qcs8300-v3-2-ee94642279ff@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: qcs8300: Adds SPMI supportTingguo Cheng
Add the SPMI bus arbiter(Version:5.2.0) node for QCS8300 SoC which connected with PMICs on QCS8300 boards. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Tingguo Cheng <quic_tingguoc@quicinc.com> Link: https://lore.kernel.org/r/20250108-adds-spmi-pmic-peripherals-for-qcs8300-v3-1-ee94642279ff@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21ARM: dts: qcom: Fix indentation errorsSanjay Chitroda
Corrected indentation issues in the qcom devicetree files as identified by ./scripts/checkpatch.pl. Signed-off-by: Sanjay Chitroda <quic_ckantibh@quicinc.com> Link: https://lore.kernel.org/r/40fc9c914f5972decbd6d639396d65bf080d3ceb.1738568609.git.quic_ckantibh@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: qcm2290: Add uart3 nodeWojciech Slenska
Add node to support uart3. Signed-off-by: Wojciech Slenska <wojciech.slenska@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20241112124651.215537-1-wojciech.slenska@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-22hyperv: Change hv_root_partition into a functionNuno Das Neves
Introduce hv_curr_partition_type to store the partition type as an enum. Right now this is limited to guest or root partition, but there will be other kinds in future and the enum is easily extensible. Set up hv_curr_partition_type early in Hyper-V initialization with hv_identify_partition_type(). hv_root_partition() just queries this value, and shouldn't be called before that. Making this check into a function sets the stage for adding a config option to gate the compilation of root partition code. In particular, hv_root_partition() can be stubbed out always be false if root partition support isn't desired. Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Easwar Hariharan <eahariha@linux.microsoft.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Link: https://lore.kernel.org/r/1740167795-13296-3-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Message-ID: <1740167795-13296-3-git-send-email-nunodasneves@linux.microsoft.com>
2025-02-21arm64: dts: qcom: qcs6490-rb3gen2: add and enable BT nodeJanaki Ramaiah Thota
Add the PMU node for WCN6750 present on the qcs6490-rb3gen2 board and assign its power outputs to the Bluetooth module. In WCN6750 module sw_ctrl and wifi-enable pins are handled in the wifi controller firmware. Therefore, it is not required to have those pins' entries in the PMU node. Signed-off-by: Janaki Ramaiah Thota <quic_janathot@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250221171014.120946-2-quic_janathot@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: sm8650: add cpu OPP table with DDR, LLCC & L3 bandwidthsNeil Armstrong
Add the OPP tables for each CPU clusters (cpu0-1, cpu2-3-4, cpu5-6 & cpu7) to permit scaling the Last Level Cache Controller (LLCC), DDR and L3 cache frequency by aggregating bandwidth requests of all CPU core with referenc to the current OPP they are configured in by the LMH/EPSS hardware. The effect is a proper caches & DDR frequency scaling when CPU cores changes frequency. The OPP tables were built using the downstream memlat ddr, llcc & l3 tables for each cluster types with the actual EPSS cpufreq LUT tables from running HDK and QRD devices. The cpu2 and cpu5 tables are similar but must be kept separate to take in account that they define OPP for shared CPUs of two different clusters that can scale separately, thus vote different bandwidths. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250211-topic-sm8650-ddr-bw-scaling-v2-3-a0c950540e68@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: sm8650: add cpu interconnect nodesNeil Armstrong
Add the interconnect entry for each cpu, with 3 different paths: - CPU to Last Level Cache Controller (LLCC) - Last Level Cache Controller (LLCC) to DDR - L3 Cache from CPU to DDR interface Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250211-topic-sm8650-ddr-bw-scaling-v2-2-a0c950540e68@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: sm8650: add OSM L3 nodeNeil Armstrong
Add the OSC L3 Cache controller node. Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250211-topic-sm8650-ddr-bw-scaling-v2-1-a0c950540e68@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: x1e80100: Add the watchdog deviceRajendra Nayak
The X Elite implements Server Base System Architecture (SBSA) specification compliant generic watchdog. Describe it. Signed-off-by: Rajendra Nayak <quic_rjendra@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20250212-x1e80100-add-watchdog-v2-1-a73897f0dad5@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21arm64: dts: qcom: qcs6490-rb3gen2: Add vadc and adc-tm channelsRakesh Kota
Add support for vadc and adc-tm channels which are used for monitoring thermistors present on the platform. - Add the necessary includes for qcom,spmi-adc7-pm7325 and qcom,spmi-adc7-pmk8350. - Add thermal zones for quiet-thermal, sdm-skin-thermal, and xo-thermal, and define their polling delays and thermal sensors. - Configure the pm7325_temp_alarm node to use the pmk8350_vadc channel for thermal monitoring. - Configure the pmk8350_adc_tm node to enable its thermal sensors and define their registers and settings. - Configure the pmk8350_vadc node to define its channels and settings Signed-off-by: Rakesh Kota <quic_kotarake@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250212113342.873086-1-quic_kotarake@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-02-21x86/arch_prctl/64: Clean up ARCH_MAP_VDSO_32Brian Gerst
process_64.c is not built on native 32-bit, so CONFIG_X86_32 will never be set. No change in functionality intended. Signed-off-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/20250202202323.422113-3-brgerst@gmail.com
2025-02-21x86/arch_prctl: Simplify sys_arch_prctl()Brian Gerst
Use in_ia32_syscall() instead of a compat syscall entry. No change in functionality intended. Signed-off-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Link: https://lore.kernel.org/r/20250202202323.422113-2-brgerst@gmail.com
2025-02-21Merge tag 'soc-fixes-6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC fixes from Arnd Bergmann: "Two people stepped up as platform co-maintainers: Andrew Jeffery for ASpeed and Janne Grunau for Apple. The rockchip platform gets 9 small fixes for devicetree files, addressing both compile-time warnings and board specific bugs. One bugfix for the optee firmware driver addresses a reboot-time hang. Two drivers need improved Kconfig dependencies to allow wider compile- testing while hiding the drivers on platforms that can't use them. ARM SCMI and loongson-guts drivers get minor bugfixes" * tag 'soc-fixes-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: soc: loongson: loongson2_guts: Add check for devm_kstrdup() tee: optee: Fix supplicant wait loop platform: cznic: CZNIC_PLATFORMS should depend on ARCH_MVEBU firmware: imx: IMX_SCMI_MISC_DRV should depend on ARCH_MXC MAINTAINERS: arm: apple: Add Janne as maintainer MAINTAINERS: Mark Andrew as M: for ASPEED MACHINE SUPPORT firmware: arm_scmi: imx: Correct tx size of scmi_imx_misc_ctrl_set arm64: dts: rockchip: adjust SMMU interrupt type on rk3588 arm64: dts: rockchip: disable IOMMU when running rk3588 in PCIe endpoint mode dt-bindings: rockchip: pmu: Ensure all properties are defined arm64: defconfig: Enable TISCI Interrupt Router and Aggregator arm64: dts: rockchip: Fix lcdpwr_en pin for Cool Pi GenBook arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices arm64: dts: rockchip: Disable DMA for uart5 on px30-ringneck arm64: dts: rockchip: Move uart5 pin configuration to px30 ringneck SoM arm64: dts: rockchip: change eth phy mode to rgmii-id for orangepi r1 plus lts arm64: dts: rockchip: Fix broken tsadc pinctrl names for rk3588
2025-02-21mips: dts: ralink: mt7620a: update system controller node and its consumersSergio Paracuellos
Current MT7620A device tree file system controller node is wrong since it is not matching bindings. Hence, update it to match current bindings updating it also to use new introduced clock constants. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-02-21mips: dts: ralink: rt3883: update system controller node and its consumersSergio Paracuellos
Current RT3883 device tree file system controller node is wrong since it is not matching bindings. Hence, update it to match current bindings updating it also to use new introduced clock constants. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-02-21mips: dts: ralink: rt3050: update system controller node and its consumersSergio Paracuellos
Current RT3050 device tree file system controller node is wrong since it is not matching bindings. Hence, update it to match current bindings updating it also to use new introduced clock constants. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-02-21mips: dts: ralink: rt2880: update system controller node and its consumersSergio Paracuellos
Current RT2880 device tree file system controller node is wrong since it is not matching bindings. Hence, update it to match current bindings updating it also to use new introduced clock constants. Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-02-21MIPS: Use arch specific syscall name match functionBibo Mao
On MIPS system, most of the syscall function name begin with prefix sys_. Some syscalls are special such as clone/fork, function name of these begin with __sys_. Since scratch registers need be saved in stack when these system calls happens. With ftrace system call method, system call functions are declared with SYSCALL_DEFINEx, metadata of the system call symbol name begins with sys_. Here mips specific function arch_syscall_match_sym_name is used to compare function name between sys_call_table[] and metadata of syscall symbol. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2025-02-21x86/efi/mixed: Move mixed mode startup code into libstubArd Biesheuvel
The EFI mixed mode code has been decoupled from the legacy decompressor, in order to be able to reuse it with generic EFI zboot images for x86. Move the source file into the libstub source directory to facilitate this. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/efi/mixed: Simplify and document thunking logicArd Biesheuvel
Now that the GDT/IDT and data segment selector preserve/restore logic has been removed from the boot-time EFI mixed mode thunking routines, the remaining logic to handle the function arguments can be simplified: the setup of the arguments on the stack can be moved into the 32-bit callee, which is able to use a more idiomatic sequence of PUSH instructions. This, in turn, allows the far call and far return to be issued using plain LCALL and LRET instructions, removing the need to set up the return explicitly. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/efi/mixed: Remove dependency on legacy startup_32 codeArd Biesheuvel
The EFI mixed mode startup code calls into startup_32 in the legacy decompressor with a mocked up boot_params struct, only to get it to set up the 1:1 mapping of the lower 4 GiB of memory and switch to a GDT that supports 64-bit mode. In order to be able to reuse the EFI mixed mode startup code in EFI zboot images, which do not incorporate the legacy decompressor code, decouple it, by dealing with the GDT and IDT directly. Doing so makes it possible to construct a GDT that is compatible with the one the firmware uses, with one additional entry for a 64-bit mode code segment appended. This removes the need entirely to switch between GDTs and IDTs or data segment selector values and all of this code can be removed. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/efi/mixed: Set up 1:1 mapping of lower 4GiB in the stubArd Biesheuvel
In preparation for dropping the dependency on startup_32 entirely in the next patch, add the code that sets up the 1:1 mapping of the lower 4 GiB of system RAM to the mixed mode stub. The reload of CR3 after the long mode switch will be removed in a subsequent patch, when it is no longer needed. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/apic: Use str_disabled_enabled() helper in print_ipi_mode()Thorsten Blum
Remove hard-coded strings by using the str_disabled_enabled() helper. No change in functionality intended. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250209210333.5666-2-thorsten.blum@linux.dev
2025-02-21x86/efi/mixed: Factor out and clean up long mode entryArd Biesheuvel
Entering long mode involves setting the EFER_LME and CR4.PAE bits before enabling paging by setting CR0.PG bit. It also involves disabling interrupts, given that the firmware's 32-bit IDT becomes invalid as soon as the CPU transitions into long mode. Reloading the CR3 register is not necessary at boot time, given that the EFI firmware as well as the kernel's EFI stub use a 1:1 mapping of the 32-bit addressable memory in the system. Break out this code into a separate helper for clarity, and so that it can be reused in a subsequent patch. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/efi/mixed: Check CPU compatibility without relying on verify_cpu()Ard Biesheuvel
In order for the EFI mixed mode startup code to be reusable in a context where the legacy decompressor is not used, replace the call to verify_cpu() [which performs an elaborate set of checks] with a simple check against the 'long mode' bit in the appropriate CPUID leaf. This is reasonable, given that EFI support is implied when booting in this manner, and so there is no need to consider very old CPUs when performing this check. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/efistub: Merge PE and handover entrypointsArd Biesheuvel
The difference between the PE and handover entrypoints in the EFI stub is that the former allocates a struct boot_params whereas the latter expects one from the caller. Currently, these are two completely separate entrypoints, duplicating some logic and both relying of efi_exit() to return straight back to the firmware on an error. Simplify this by making the PE entrypoint call the handover entrypoint with NULL as the argument for the struct boot_params parameter. This makes the code easier to follow, and removes the need to support two different calling conventions in the mixed mode asm code. While at it, move the assignment of boot_params_ptr into the function that actually calls into the legacy decompressor, which is where its value is required. Acked-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-02-21x86/platform/olpc-xo1-sci: Don't include <linux/pm_wakeup.h> directlyWolfram Sang
The header clearly states that it does not want to be included directly, only via <linux/(platform_)?device.h>. Which is already present, so delete the superfluous include. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250210113453.51825-2-wsa+renesas@sang-engineering.com
2025-02-21x86/pat: Fix W=1 build warning when the within_inclusive() function is unusedAndy Shevchenko
The within_inclusive() function, in some cases, when CONFIG_X86_64=n, may be not used. This, in particular, prevents kernel builds with Clang, `make W=1` and CONFIG_WERROR=y: arch/x86/mm/pat/set_memory.c:215:1: error: unused function 'within_inclusive' [-Werror,-Wunused-function] Fix this by guarding the definitions with the respective ifdeffery. See also: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250211145721.1620552-1-andriy.shevchenko@linux.intel.com