summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2026-01-06arm64: dts: rockchip: Enable the NPU on FriendlyElec CM3588Ricardo Pardini
Enable the NPU on FriendlyElec CM3588. The regulator vdd_npu_s0 was already in place; since the NPU power domain supply is now described, remove the regulator's always-on. Signed-off-by: Ricardo Pardini <ricardo@pardini.net> Link: https://patch.msgid.link/20260101-arm64-dts-rockchip-rk3588-npu-enablements-v2-2-013cf5d5c39d@pardini.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-06arm64: dts: rockchip: Enable the NPU on NanoPC T6/T6-LTSRicardo Pardini
Enable the NPU on FriendlyElec NanoPC T6/T6-LTS boards. The regulator vdd_npu_s0 was already in place; since the NPU power domain supply is now described, remove the regulator's always-on. Signed-off-by: Ricardo Pardini <ricardo@pardini.net> Link: https://patch.msgid.link/20260101-arm64-dts-rockchip-rk3588-npu-enablements-v2-1-013cf5d5c39d@pardini.net Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-06arm64: dts: rockchip: enable UFS controller on FriendlyElec NanoPi M5Alexey Charkov
The NanoPi M5 board supports pluggable UFS modules using the UFSHC inside its Rockchip RK3576 SoC. Enable the respective devicetree node and add its supply regulators. Link: https://wiki.friendlyelec.com/wiki/images/9/97/NanoPi_M5_LP5_2411_SCH.pdf Signed-off-by: Alexey Charkov <alchark@gmail.com> Link: https://patch.msgid.link/20251230-nanopi-m5-ufs-v3-1-ed188ae34fdb@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-06arm64: dts: rockchip: Add light/proximity sensor to Pinephone ProOndrej Jirman
Pinephone Pro uses STK3311 according to the schematics. Tests: ~ $ monitor-sensor --light // When the sensor is exposed, it get's fluctating values such as Light changed: 1.800000 (lux) Light changed: 1.700000 (lux) Light changed: 1.800000 (lux) Light changed: 1.700000 (lux) Light changed: 1.600000 (lux) Light changed: 1.100000 (lux) // When covering the sensor, it prints a low value and stops printing Light changed: 0.200000 (lux) ~ $ monitor-sensor --proximity // When it goes away from an object Proximity value changed: 0 // When it comes near an object Proximity value changed: 1 Co-developed-by: Martijn Braam <martijn@brixit.nl> Signed-off-by: Martijn Braam <martijn@brixit.nl> Co-developed-by: Kamil Trzciński <ayufan@ayufan.eu> Signed-off-by: Kamil Trzciński <ayufan@ayufan.eu> Signed-off-by: Ondrej Jirman <megi@xff.cz> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com> Link: https://patch.msgid.link/20251225-ppp_light_accel_mag_vol-down-v6-2-8c79a4e87001@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-06arm64: dts: rockchip: Add magnetometer sensor to Pinephone ProOndrej Jirman
Pinephone Pro uses AF8133J according to the schematic. The mount-matrix was added by Leonardo on top of Ondrej's work of adding the magnetometer. It was verified with Leonardo's compass app: https://gitlab.com/lgtrombetta/compass Co-developed-by: Leonardo G. Trombetta <lgtrombetta@gmx.com> Signed-off-by: Leonardo G. Trombetta <lgtrombetta@gmx.com> Signed-off-by: Ondrej Jirman <megi@xff.cz> Reviewed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com> Link: https://patch.msgid.link/20251225-ppp_light_accel_mag_vol-down-v6-1-8c79a4e87001@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-07ARM: dts: allwinner: sun5i-a13-utoo-p66: delete "power-gpios" propertyChen-Yu Tsai
The P66's device tree includes the reference design dtsi files, which defines a node and properties for the touchpanel in the common design. The P66 dts file then overrides all the properties to match its own design, but as the touchpanel model is different, a different schema is matched. This other schema uses a different name for the GPIO. The original submission added the correct GPIO property, but did not delete the one inherited from the reference design, causing validation errors. Explicitly delete the incorrect GPIO property. Fixes: 2a53aff27236 ("ARM: dts: sun5i: Enable touchscreen on Utoo P66") Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251225103616.3203473-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
2026-01-06arm64: dts: qcom: qcs615-ride: Enable DisplayPortXiangxu Yin
Add DP connector node and configure MDSS DisplayPort controller for QCS615 Ride platform. Include PHY supply settings to support DP output. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251104-add-displayport-support-to-qcs615-devicetree-v7-4-e51669170a6f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-06arm64: dts: qcom: talos: Add DisplayPort and QMP USB3-DP PHYXiangxu Yin
Introduce DisplayPort controller node and associated QMP USB3-DP PHY for SM6150 SoC. Add data-lanes property to the DP endpoint and update clock assignments for proper DP integration. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Xiangxu Yin <xiangxu.yin@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251104-add-displayport-support-to-qcs615-devicetree-v7-3-e51669170a6f@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-06x86/tsx: Set default TSX mode to autoNikolay Borisov
At SUSE we've been releasing our kernels with TSX enabled for the past 6 years and some customers have started to rely on it. Furthermore, the last known vulnerability concerning TSX was TAA (CVE-2019-11135) and a significant amount time has passed since then without anyone reporting any issues. Intel has released numerous processors which do not have the TAA vulnerability (Cooper/Ice Lake, Sapphire/Emerald/Granite Rappids) yet TSX remains being disabled by default. The main aim of this patch is to reduce the divergence between SUSE's configuration and the upstream by switching the default TSX mode to auto. I believe this strikes the right balance between keeping it enabled where appropriate (i.e every machine which doesn't contain the TAA vulnerability) and disabling it preventively. Signed-off-by: Nikolay Borisov <nik.borisov@suse.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://patch.msgid.link/20251112190548.750746-1-nik.borisov@suse.com
2026-01-06x86/cpu: Drop unused Kconfig symbol X86_P6_NOPRandy Dunlap
This symbol was removed in early 2025 but 2 dangling references to it were missed. Delete them now. It should be safe to drop the -mtune=generic32 option since gcc 4.3 and later do not cause the problem (see 28f7e66fc1da ("x86: prevent binutils from being "smart" and generating NOPLs for us")). Also, Arnd confirmed this with gcc-8 and gcc-15 (see Link:). Fixes: f388f60ca904 ("x86/cpu: Drop configuration options for early 64-bit CPUs") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Link: https://patch.msgid.link/20260106014708.991447-1-rdunlap@infradead.org Link: https://lore.kernel.org/all/c0f0814a-8333-49e1-8e50-740e4c88d94b@app.fastmail.com/
2026-01-06arm64: dts: qcom: sm8750-qrd: Enable Iris codecKrzysztof Kozlowski
Enable on SM8750 QRD the Iris video codec for accelerated video encoding/decoding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20260106-b4-sm8750-iris-dts-v4-3-97db1d1df3dd@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-06arm64: dts: qcom: sm8750-mtp: Enable Iris codecKrzysztof Kozlowski
Enable on SM8750 MTP the Iris video codec for accelerated video encoding/decoding. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20260106-b4-sm8750-iris-dts-v4-2-97db1d1df3dd@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-06arm64: dts: qcom: sm8750: Add Iris VPU v3.5Krzysztof Kozlowski
Add Iris video codec to SM8750 SoC, which comes with significantly different powering up sequence than previous SM8650, thus different clocks and resets. For consistency keep existing clock and clock-names naming, so the list shares common part. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20260106-b4-sm8750-iris-dts-v4-1-97db1d1df3dd@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-06arm/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()Keke Ming
Replace deprecated kmap_atomic() with kmap_local_page(). Signed-off-by: Keke Ming <ming.jvle@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260103084243.195125-5-ming.jvle@gmail.com
2026-01-06mips/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()Keke Ming
Replace deprecated kmap_atomic() with kmap_local_page(). Signed-off-by: Keke Ming <ming.jvle@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260103084243.195125-4-ming.jvle@gmail.com
2026-01-06arm64/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()Keke Ming
Replace deprecated kmap_atomic() with kmap_local_page(). Signed-off-by: Keke Ming <ming.jvle@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260103084243.195125-3-ming.jvle@gmail.com
2026-01-06riscv/uprobes: use kmap_local_page() in arch_uprobe_copy_ixol()Keke Ming
Replace deprecated kmap_atomic() with kmap_local_page(). Signed-off-by: Keke Ming <ming.jvle@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260103084243.195125-2-ming.jvle@gmail.com
2026-01-06perf/x86/intel/uncore: Add Nova Lake supportZide Chen
Nova Lake uncore PMON largely follows Panther Lake and supports CBOX, iMC, cNCU, SANTA, sNCU, and HBO units. As with Panther Lake, CBOX, cNCU, and SANTA are not enumerated via discovery tables. Their programming model matches Panther Lake, with differences limited to MSR addresses and the number of boxes or counters per box. The remaining units are enumerated via discovery tables using a new base MSR (0x711) and otherwise reuse the Panther Lake implementation. Nova Lake also supports iMC free-running counters. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-14-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Add missing PMON units for Panther LakeZide Chen
Besides CBOX, Panther Lake includes several legacy uncore PMON units not enumerated via discovery tables, including cNCU, SANTA, and ia_core_bridge. The cNCU PMON is similar to Meteor Lake but has two boxes with two counters each. SANTA and IA Core Bridge PMON units follow the legacy model used on Lunar Lake, Meteor Lake, and others. Panther Lake implements the Global Control Register; the freeze_all bit must be cleared before programming counters. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-13-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Update DMR uncore constraints preliminarilyZide Chen
Update event constraints base on the latest DMR uncore event list. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-11-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Support uncore constraint rangesZide Chen
Add UNCORE_EVENT_CONSTRAINT_RANGE macro for uncore constraints, similar to INTEL_EVENT_CONSTRAINT_RANGE, to reduce duplication when defining consecutive uncore event constraints. No functional change intended. Suggested-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-10-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Support IIO free-running counters on DMRZide Chen
The free-running counters for IIO uncore blocks on Diamond Rapids are similar to Sapphire Rapids IMC freecounters, with the following differences: - The counters are MMIO based. - Only a subset of IP blocks implement free-running counters: HIOP0 (IP Base Addr: 2E7000h) HIOP1 (IP Base Addr: 2EF000h) HIOP3 (IP Base Addr: 2FF000h) HIOP4 (IP Base Addr: 307000h) - IMH2 (Secondary IMH) does not provide free-running counters. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-9-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Add freerunning event descriptor helper macroZide Chen
Freerunning counter events are repetitive: the event code is fixed to 0xff, the unit is always "MiB", and the scale is identical across all counters on a given PMON unit. Introduce a new helper macro, INTEL_UNCORE_FR_EVENT_DESC(), to populate the event, scale, and unit descriptor triplet. This reduces duplicated lines and improves readability. No functional change intended. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-8-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Add domain global init callbackZide Chen
In the Intel uncore self-describing mechanism, the Global Control Register freeze_all bit is SoC-wide and propagates to all uncore PMUs. On Diamond Rapids, this bit is set at power-on, unlike some prior platforms. Add a global_init callback to unfreeze all PMON units. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-7-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Add CBB PMON support for Diamond RapidsZide Chen
On DMR, PMON units inside the Core Building Block (CBB) are enumerated separately from those in the Integrated Memory and I/O Hub (IMH). A new per-CBB MSR (0x710) is introduced for discovery table enumeration. For counter control registers, the tid_en bit (bit 16) exists on CBO, SBO, and Santa, but it is not used by any events. Mark this bit as reserved. Similarly, disallow extended umask (bits 32–63) on Santa and sNCU. Additionally, ignore broken SB2UCIE unit. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-6-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Add IMH PMON support for Diamond RapidsZide Chen
DMR supports IMH PMON units for PCU, UBox, iMC, and CXL: - PCU and UBox are same with SPR. - iMC is similar to SPR but uses different offsets for fixed registers. - CXL introduces a new port_enable field and changes the position of the threshold field. DMR also introduces additional PMON units: SCA, HAMVF, D2D_ULA, UBR, PCIE4, CRS, CPC, ITC, OTC, CMS, and PCIE6. Among these, PCIE4 and PCIE6 use different unit types, but share the same config register layout, and the generic PCIe PMON events apply to both. Additionally, ignore the broken MSE unit. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251231224233.113839-5-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Remove has_generic_discovery_table()Zide Chen
In the !x86_match_cpu() fallback path, has_generic_discovery_table() is removed because it does not handle multiple PCI devices. Instead, use PCI_ANY_ID in generic_uncore_init[] to probe all PCI devices. For MSR portals, only probe MSR 0x201e to keep the fallback simple, as this path is best-effort only. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-4-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Support per-platform discovery base devicesZide Chen
On DMR platforms, IMH discovery tables are enumerated via PCI, while CBB domains use MSRs, unlike earlier platforms which relied on either PCI or MSR exclusively. DMR also uses different MSRs and PCI devices, requiring support for multiple, platform-specific discovery bases. Introduce struct uncore_discovery_domain to hold the discovery base and other domain-specific configuration. Move uncore_units_ignore into uncore_discovery_domain so a single structure can be passed to uncore_discovery_[pci/msr]. No functional change intended. Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-3-zide.chen@intel.com
2026-01-06perf/x86/intel/uncore: Move uncore discovery init struct to headerZide Chen
The discovery base MSR or PCI device is platform-specific and must be defined statically in the per-platform init table and passed to the discovery code. Move the definition of struct intel_uncore_init_fun to uncore.h so it can be accessed by discovery code, and rename it to reflect that it now carries more than just init callbacks. Shorten intel_uncore_has_discovery_tables[_pci/msr] to uncore_discovery[_pci/msr] for improved readability and alignment. Drop the `intel_` prefix from new names since the code is under the intel directory and long identifiers make alignment harder. Further cleanups will continue removing `intel_` prefixes. No functional change intended. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251231224233.113839-2-zide.chen@intel.com
2026-01-06perf/x86/uncore: clean up const mismatchGreg Kroah-Hartman
In some cmp functions, a const pointer is cast out to a non-const pointer by using container_of() which is not correct. Fix this up by properly marking the pointers as const, which preserves the correct type of the pointer passed into the functions. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/2025121741-headstand-stratus-f5eb@gregkh
2026-01-06arm64/efi: Don't fail check current_in_efi() if preemptibleBen Horgan
As EFI runtime services can now be run without disabling preemption remove the check for non preemptible in current_in_efi(). Without this change, firmware errors that were previously recovered from by __efi_runtime_kernel_fixup_exception() will lead to a kernel oops. Fixes: a5baf582f4c0 ("arm64/efi: Call EFI runtime services without disabling preemption") Signed-off-by: Ben Horgan <ben.horgan@arm.com> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Richard Lyu <richard.lyu@suse.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-01-06arm64: zynqmp: Remove ina260 IIO descriptionMichal Simek
Kernel has only hwmon driver that's why there is no reason to wire iio to hwmon converter which was describing out of tree ina260 IIO. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/7e57f76deca9e73be3fcb914aed119f567c9bf8a.1765785722.git.michal.simek@amd.com
2026-01-06arm64: dts: xilinx: Drop "label" property on dlg,slg7xl45106Rob Herring (Arm)
The "label" property is not documented for the dlg,slg7xl45106. Nor is it common to use for GPIO controllers. So drop it. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20251216175914.2791200-1-robh@kernel.org
2026-01-05x86/kaslr: Recognize all ZONE_DEVICE users as physaddr consumersDan Williams
Commit 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") is too narrow. The effect being mitigated in that commit is caused by ZONE_DEVICE which PCI_P2PDMA has a dependency. ZONE_DEVICE, in general, lets any physical address be added to the direct-map. I.e. not only ACPI hotplug ranges, CXL Memory Windows, or EFI Specific Purpose Memory, but also any PCI MMIO range for the DEVICE_PRIVATE and PCI_P2PDMA cases. Update the mitigation, limit KASLR entropy, to apply in all ZONE_DEVICE=y cases. Distro kernels typically have PCI_P2PDMA=y, so the practical exposure of this problem is limited to the PCI_P2PDMA=n case. A potential path to recover entropy would be to walk ACPI and determine the limits for hotplug and PCI MMIO before kernel_randomize_memory(). On smaller systems that could yield some KASLR address bits. This needs additional investigation to determine if some limited ACPI table scanning can happen this early without an open coded solution like arch/x86/boot/compressed/acpi.c needs to deploy. Cc: Ingo Molnar <mingo@kernel.org> Cc: Kees Cook <kees@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Logan Gunthorpe <logang@deltatee.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Hildenbrand <david@redhat.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: "Liam R. Howlett" <Liam.Howlett@oracle.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Michal Hocko <mhocko@suse.com> Fixes: 7ffb791423c7 ("x86/kaslr: Reduce KASLR entropy on most x86 systems") Cc: <stable@vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Reviewed-by: Balbir Singh <balbirs@nvidia.com> Tested-by: Yasunori Goto <y-goto@fujitsu.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Link: http://patch.msgid.link/692e08b2516d4_261c1100a3@dwillia2-mobl4.notmuch Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-01-05riscv: kexec_image: Fix dead link to boot-image-header.rstSoham Metha
Fix the reference to 'boot-image-header.rst', which was moved to 'Documentation/arch/riscv/' in commit 'ed843ae947f8' ("docs: move riscv under arch"). Signed-off-by: Soham Metha <sohammetha01@gmail.com> Link: https://patch.msgid.link/20251203194355.63265-1-sohammetha01@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-05riscv: pgtable: Cleanup useless VA_USER_XXX definitionsGuo Ren (Alibaba DAMO Academy)
These marcos are not used after commit b5b4287accd7 ("riscv: mm: Use hint address in mmap if available"). Cleanup VA_USER_XXX definitions in asm/pgtable.h. Fixes: b5b4287accd7 ("riscv: mm: Use hint address in mmap if available") Signed-off-by: Guo Ren (Alibaba DAMO Academy) <guoren@kernel.org> Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com> Link: https://patch.msgid.link/20251201005850.702569-1-guoren@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-05riscv: cpufeature: Fix Zk bundled extension missing ZknhGuodong Xu
The Zk extension is a bundle consisting of Zkn, Zkr, and Zkt. The Zkn extension itself is a bundle consisting of Zbkb, Zbkc, Zbkx, Zknd, Zkne, and Zknh. The current implementation of riscv_zk_bundled_exts manually listed the dependencies but missed RISCV_ISA_EXT_ZKNH. Fix this by introducing a RISCV_ISA_EXT_ZKN macro that lists the Zkn components and using it in both riscv_zk_bundled_exts and riscv_zkn_bundled_exts. This adds the missing Zknh extension to Zk and reduces code duplication. Fixes: 0d8295ed975b ("riscv: add ISA extension parsing for scalar crypto") Link: https://patch.msgid.link/20231114141256.126749-4-cleger@rivosinc.com/ Signed-off-by: Guodong Xu <guodong@riscstar.com> Reviewed-by: Clément Léger <cleger@rivosinc.com> Link: https://patch.msgid.link/20251223-zk-missing-zknh-v1-1-b627c990ee1a@riscstar.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-05arm64: dts: qcom: Add The Fairphone (Gen. 6)Luca Weiss
Add a devicetree for The Fairphone (Gen. 6) smartphone, which is based on the Milos/SM7635 SoC. Supported functionality as of this initial submission: * Debug UART * Regulators (PM7550, PM8550VS, PMR735B, PM8008) * Remoteprocs (ADSP, CDSP, MPSS, WPSS) * Power Button, Volume Keys, Switch * PMIC-GLINK (Charger, Fuel gauge, USB-C mode switching) * Camera flash/torch LED * SD card * USB Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251210-sm7635-fp6-initial-v4-9-b05fddd8b45c@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-05arm64: dts: qcom: Add initial Milos dtsiLuca Weiss
Add a devicetree description for the Milos SoC, which is for example Snapdragon 7s Gen 3 (SM7635). Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251210-sm7635-fp6-initial-v4-8-b05fddd8b45c@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-05arm64: dts: qcom: Add PMIV0104 PMICLuca Weiss
Add a dts for the PMIC used e.g. on devices with the Milos SoC. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20251210-sm7635-fp6-initial-v4-7-b05fddd8b45c@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-05arm64: dts: qcom: Add PM7550 PMICLuca Weiss
Add a dts for the PMIC used e.g. with Milos SoC-based devices. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251210-sm7635-fp6-initial-v4-6-b05fddd8b45c@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-05arm64: dts: qcom: pm8550vs: Disable different PMIC SIDs by defaultLuca Weiss
Keep the different PMIC definitions in pm8550vs.dtsi disabled by default, and only enable them in boards explicitly. This allows to support boards better which only have pm8550vs_c, like the Milos/SM7635-based Fairphone (Gen. 6). Note: I assume that at least some of these devices with PM8550VS also don't have _c, _d, _e and _g, but this patch is keeping the resulting devicetree the same as before this change, disabling them on boards that don't actually have those is out of scope for this patch. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20251210-sm7635-fp6-initial-v4-5-b05fddd8b45c@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-05arm64: kernel: initialize missing kexec_buf->random fieldYeoreum Yun
Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_Bool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3 PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Suggested-by: Breno Leitao <leitao@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/20250825180531.94bfb86a26a43127c0a1296f@linux-foundation.org/ [2] Link: https://lkml.kernel.org/r/20250826-akpm-v1-1-3c831f0e3799@debian.org Signed-off-by: Breno Leitao <leitao@debian.org> Suggested-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-05arm64: topology: Handle AMU FIE setup on CPU hotplugLifeng Zheng
Currently, when a cpufreq policy is created, the AMU FIE setup process checks all CPUs in the policy -- including those that are offline. If any of these CPUs are offline at that time, their AMU capability flag hasn't been verified yet, leading the check fail. As a result, AMU FIE is not enabled, even if the CPUs that are online do support it. Later, when the previously offline CPUs come online and report AMU support, there's no mechanism in place to re-enable AMU FIE for the policy. This leaves the entire frequency domain without AMU FIE, despite being eligible. Restrict the initial AMU FIE check to only those CPUs that are online at the time the policy is created, and allow CPUs that come online later to join the policy with AMU FIE enabled. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Acked-by: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-05arm64: topology: Skip already covered CPUs when setting freq sourceLifeng Zheng
The scale freq source of the CPUs in 'amu_fie_cpus' mask are already set to AMU tick before, so in amu_fie_setup(), only the CPUs in the 'cpus' mask should be set. Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com> Reviewed-by: Beata Michalska <beata.michalska@arm.com> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com> Acked-by: Beata Michalska <beata.michalska@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-05arm64: Add support for TSV110 Spectre-BHB mitigationJinqian Yang
The TSV110 processor is vulnerable to the Spectre-BHB (Branch History Buffer) attack, which can be exploited to leak information through branch prediction side channels. This commit adds the MIDR of TSV110 to the list for software mitigation. Signed-off-by: Jinqian Yang <yangjinqian1@huawei.com> Reviewed-by: Zenghui Yu <zenghui.yu@linux.dev> Signed-off-by: Will Deacon <will@kernel.org>
2026-01-05ARM: dts: omap: dra7: Remove bogus #syscon-cells propertyVladimir Zapolskiy
There is no such dt binding property as '#syscon-cells', remove it. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251230234040.2083889-1-vz@mleia.com Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2026-01-05ARM: omap1: drop unused Kconfig symbolRandy Dunlap
"select ARCH_HAS_HOLES_MEMORYMODEL" was mistakenly merged here due to a botched rebase (says Arnd [1]). Drop that line since that symbol is not used anywhere else in the kernel source tree. [1] https://lore.kernel.org/all/5e335232-89b4-4c35-93bd-efad7e4d8995@app.fastmail.com/ Fixes: 7036440eab3e ("ARM: omap1: enable multiplatform") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Aaro Koskinen <aaro.koskinen@iki.fi> Link: https://patch.msgid.link/20251230055230.3212260-1-rdunlap@infradead.org Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2026-01-05ARM: dts: ti/omap: omap*: fix watchdog node namesAndreas Kemnade
Watchdog nodes should be named watchdog@ and not wdg@. Fix that. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20251224093457.558477-1-andreas@kemnade.info Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2026-01-05ARM: omap2: Fix reference count leaks in omap_control_init()Wentao Liang
The of_get_child_by_name() function increments the reference count of child nodes, causing multiple reference leaks in omap_control_init(): 1. scm_conf node never released in normal/error paths 2. clocks node leak when checking existence 3. Missing scm_conf release before np in error paths Fix these leaks by adding proper of_node_put() calls and separate error handling. Fixes: e5b635742e98 ("ARM: OMAP2+: control: add syscon support for register accesses") Cc: stable@vger.kernel.org Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Reviewed-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20251217142122.1861292-1-vulab@iscas.ac.cn Signed-off-by: Kevin Hilman <khilman@baylibre.com>