summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2025-12-18x86/bug: Fix old GCC compile failsPeter Zijlstra1-1/+1
For some mysterious reasons the GCC 8 and 9 preprocessor manages to sporadically fumble _ASM_BYTES(0x0f, 0x0b): $ grep ".byte[ ]*0x0f" defconfig-build/drivers/net/wireless/realtek/rtlwifi/base.s 1: .byte0x0f,0x0b ; 1: .byte 0x0f,0x0b ; which makes the assembler upset and all that. While there are more _ASM_BYTES() users (notably the NOP instructions), those don't seem affected. Therefore replace the offending ASM_UD2 with one using the ud2 mnemonic. Reported-by: Jean Delvare <jdelvare@suse.de> Suggested-by: Uros Bizjak <ubizjak@gmail.com> Fixes: 85a2d4a890dc ("x86,ibt: Use UDB instead of 0xEA") Cc: stable@kernel.org Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251218104659.GT3911114@noisy.programming.kicks-ass.net
2025-12-18arm64: dts: qcom: glymur: Add header file for IPCC physical client IDsSibi Sankar1-0/+68
Physical client IDs are used on Glymur Inter Process Communication Controller (IPCC), add a corresponding header file. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251031-knp-ipcc-v3-3-62ffb4168dff@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-18arm64: dts: qcom: kaanapali: Add header file for IPCC physical client IDsJingyi Wang1-0/+58
On earlier platforms, Inter Process Communication Controller (IPCC) used virtual client IDs and performed virtual-to-physical mapping in hardware, so the IDs defined in dt-bindings/mailbox/qcom-ipcc.h are common across platforms. Physical client IDs instead of virtual client IDs are used for qcom new platforms like Kaanapali, which will be parsed by the devicetree and passed to hardware to use Physical client IDs directly. Since physical client IDs could vary across platforms, add a corresponding header file for the Kaanapali platform. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251031-knp-ipcc-v3-2-62ffb4168dff@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17x86/msi: Make irq_retrigger() functional for posted MSIThomas Gleixner2-0/+30
Luigi reported that retriggering a posted MSI interrupt does not work correctly. The reason is that the retrigger happens at the vector domain by sending an IPI to the actual vector on the target CPU. That works correctly exactly once because the posted MSI interrupt chip does not issue an EOI as that's only required for the posted MSI notification vector itself. As a consequence the vector becomes stale in the ISR, which not only affects this vector but also any lower priority vector in the affected APIC because the ISR bit is not cleared. Luigi proposed to set the vector in the remap PIR bitmap and raise the posted MSI notification vector. That works, but that still does not cure a related problem: If there is ever a stray interrupt on such a vector, then the related APIC ISR bit becomes stale due to the lack of EOI as described above. Unlikely to happen, but if it happens it's not debuggable at all. So instead of playing games with the PIR, this can be actually solved for both cases by: 1) Keeping track of the posted interrupt vector handler state 2) Implementing a posted MSI specific irq_ack() callback which checks that state. If the posted vector handler is inactive it issues an EOI, otherwise it delegates that to the posted handler. This is correct versus affinity changes and concurrent events on the posted vector as the actual handler invocation is serialized through the interrupt descriptor lock. Fixes: ed1e48ea4370 ("iommu/vt-d: Enable posted mode for device MSIs") Reported-by: Luigi Rizzo <lrizzo@google.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Luigi Rizzo <lrizzo@google.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251125214631.044440658@linutronix.de Closes: https://lore.kernel.org/lkml/20251124104836.3685533-1-lrizzo@google.com
2025-12-17perf/x86/cstate: Add Airmont NPMartin Schiller1-0/+1
From the perspective of Intel cstate residency counters, the Airmont NP (aka Lightning Mountain) is identical to the Airmont. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251124074846.9653-4-ms@dev.tdt.de
2025-12-17perf/x86/intel: Add Airmont NPMartin Schiller1-0/+1
The Intel / MaxLinear Airmont NP (aka Lightning Mountain) supports the same architectual and non-architecural events as Airmont. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251124074846.9653-3-ms@dev.tdt.de
2025-12-17perf/x86/msr: Add Airmont NPMartin Schiller1-0/+1
Like Airmont, the Airmont NP (aka Intel / MaxLinear Lightning Mountain) supports SMI_COUNT MSR. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251124074846.9653-2-ms@dev.tdt.de
2025-12-17x86/unwind_user: Simplify unwind_user_word_size()Jens Remus1-5/+1
Get rid of superfluous ifdef and return explicit word size depending on 32-bit or 64-bit mode. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251208160352.1363040-5-jremus@linux.ibm.com
2025-12-17x86/unwind_user: Guard unwind_user_word_size() by UNWIND_USERJens Remus1-13/+17
The unwind user framework in general requires an architecture-specific implementation of unwind_user_word_size() to be present for any unwind method, whether that is fp or a future other method, such as potentially sframe. Guard unwind_user_word_size() by the availability of the UNWIND_USER framework instead of the specific HAVE_UNWIND_USER_FP method. This facilitates to selectively disable HAVE_UNWIND_USER_FP on x86 (e.g. for test purposes) once a new unwind method is added to unwind user. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251208160352.1363040-4-jremus@linux.ibm.com
2025-12-17unwind_user/fp: Use dummies instead of ifdefJens Remus1-0/+1
This simplifies the code. unwind_user_next_fp() does not need to return -EINVAL if config option HAVE_UNWIND_USER_FP is disabled, as unwind_user_start() will then not select this unwind method and unwind_user_next() will therefore not call it. Provide (1) a dummy definition of ARCH_INIT_USER_FP_FRAME, if the unwind user method HAVE_UNWIND_USER_FP is not enabled, (2) a common fallback definition of unwind_user_at_function_start() which returns false, and (3) a common dummy definition of ARCH_INIT_USER_FP_ENTRY_FRAME. Note that enabling the config option HAVE_UNWIND_USER_FP without defining ARCH_INIT_USER_FP_FRAME triggers a compile error, which is helpful when implementing support for this unwind user method in an architecture. Enabling the config option when providing an arch- specific unwind_user_at_function_start() definition makes it necessary to also provide an arch-specific ARCH_INIT_USER_FP_ENTRY_FRAME definition. Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251208160352.1363040-3-jremus@linux.ibm.com
2025-12-17perf/x86/amd: Support PERF_PMU_CAP_MEDIATED_VPMU for AMD hostSandipan Das1-0/+2
Apply the PERF_PMU_CAP_MEDIATED_VPMU flag for version 2 and later implementations of the core PMU. Aside from having Global Control and Status registers, virtualizing the PMU using the mediated model requires an interface to set or clear the overflow bits in the Global Status MSRs while restoring or saving the PMU context of a vCPU. PerfMonV2-capable hardware has additional MSRs for this purpose, namely PerfCntrGlobalStatusSet and PerfCntrGlobalStatusClr, thereby making it suitable for use with mediated vPMU. Signed-off-by: Sandipan Das <sandipan.das@amd.com> Signed-off-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Xudong Hao <xudong.hao@intel.com> Link: https://patch.msgid.link/20251206001720.468579-14-seanjc@google.com
2025-12-17perf/x86/intel: Support PERF_PMU_CAP_MEDIATED_VPMUKan Liang1-0/+5
Apply the PERF_PMU_CAP_MEDIATED_VPMU for Intel core PMU. It only indicates that the perf side of core PMU is ready to support the mediated vPMU. Besides the capability, the hypervisor, a.k.a. KVM, still needs to check the PMU version and other PMU features/capabilities to decide whether to enable support mediated vPMUs. [sean: massage changelog] Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Xudong Hao <xudong.hao@intel.com> Link: https://patch.msgid.link/20251206001720.468579-13-seanjc@google.com
2025-12-17perf/x86/core: Plumb mediated PMU capability from x86_pmu to x86_pmu_capMingwei Zhang2-0/+2
Plumb mediated PMU capability to x86_pmu_cap in order to let any kernel entity such as KVM know that host PMU support mediated PMU mode and has the implementation. Signed-off-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Xudong Hao <xudong.hao@intel.com> Link: https://patch.msgid.link/20251206001720.468579-12-seanjc@google.com
2025-12-17perf/x86/core: Do not set bit width for unavailable countersSandipan Das1-2/+2
Not all x86 processors have fixed counters. It may also be the case that a processor has only fixed counters and no general-purpose counters. Set the bit widths corresponding to each counter type only if such counters are available. Fixes: b3d9468a8bd2 ("perf, x86: Expose perf capability to other modules") Signed-off-by: Sandipan Das <sandipan.das@amd.com> Co-developed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Xudong Hao <xudong.hao@intel.com> Link: https://patch.msgid.link/20251206001720.468579-11-seanjc@google.com
2025-12-17perf/x86/core: Add APIs to switch to/from mediated PMI vector (for KVM)Sean Christopherson2-0/+37
Add APIs (exported only for KVM) to switch PMIs to the dedicated mediated PMU IRQ vector when loading guest context, and back to perf's standard NMI when the guest context is put. I.e. route PMIs to PERF_GUEST_MEDIATED_PMI_VECTOR when the guest context is active, and to NMIs while the host context is active. While running with guest context loaded, ignore all NMIs (in perf). Any NMI that arrives while the LVTPC points at the mediated PMU IRQ vector can't possibly be due to a host perf event. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251206001720.468579-10-seanjc@google.com
2025-12-17perf/x86/core: Register a new vector for handling mediated guest PMIsSean Christopherson6-1/+35
Wire up system vector 0xf5 for handling PMIs (i.e. interrupts delivered through the LVTPC) while running KVM guests with a mediated PMU. Perf currently delivers all PMIs as NMIs, e.g. so that events that trigger while IRQs are disabled aren't delayed and generate useless records, but due to the multiplexing of NMIs throughout the system, correctly identifying NMIs for a mediated PMU is practically infeasible. To (greatly) simplify identifying guest mediated PMU PMIs, perf will switch the CPU's LVTPC between PERF_GUEST_MEDIATED_PMI_VECTOR and NMI when guest PMU context is loaded/put. I.e. PMIs that are generated by the CPU while the guest is active will be identified purely based on the IRQ vector. Route the vector through perf, e.g. as opposed to letting KVM attach a handler directly a la posted interrupt notification vectors, as perf owns the LVTPC and thus is the rightful owner of PERF_GUEST_MEDIATED_PMI_VECTOR. Functionally, having KVM directly own the vector would be fine (both KVM and perf will be completely aware of when a mediated PMU is active), but would lead to an undesirable split in ownership: perf would be responsible for installing the vector, but not handling the resulting IRQs. Add a new perf_guest_info_callbacks hook (and static call) to allow KVM to register its handler with perf when running guests with mediated PMUs. Note, because KVM always runs guests with host IRQs enabled, there is no danger of a PMI being delayed from the guest's perspective due to using a regular IRQ instead of an NMI. Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Xudong Hao <xudong.hao@intel.com> Link: https://patch.msgid.link/20251206001720.468579-9-seanjc@google.com
2025-12-17perf: Add APIs to create/release mediated guest vPMUsKan Liang1-0/+1
Currently, exposing PMU capabilities to a KVM guest is done by emulating guest PMCs via host perf events, i.e. by having KVM be "just" another user of perf. As a result, the guest and host are effectively competing for resources, and emulating guest accesses to vPMU resources requires expensive actions (expensive relative to the native instruction). The overhead and resource competition results in degraded guest performance and ultimately very poor vPMU accuracy. To address the issues with the perf-emulated vPMU, introduce a "mediated vPMU", where the data plane (PMCs and enable/disable knobs) is exposed directly to the guest, but the control plane (event selectors and access to fixed counters) is managed by KVM (via MSR interceptions). To allow host perf usage of the PMU to (partially) co-exist with KVM/guest usage of the PMU, KVM and perf will coordinate to a world switch between host perf context and guest vPMU context near VM-Enter/VM-Exit. Add two exported APIs, perf_{create,release}_mediated_pmu(), to allow KVM to create and release a mediated PMU instance (per VM). Because host perf context will be deactivated while the guest is running, mediated PMU usage will be mutually exclusive with perf analysis of the guest, i.e. perf events that do NOT exclude the guest will not behave as expected. To avoid silent failure of !exclude_guest perf events, disallow creating a mediated PMU if there are active !exclude_guest events, and on the perf side, disallowing creating new !exclude_guest perf events while there is at least one active mediated PMU. Exempt PMU resources that do not support mediated PMU usage, i.e. that are outside the scope/view of KVM's vPMU and will not be swapped out while the guest is running. Guard mediated PMU with a new kconfig to help readers identify code paths that are unique to mediated PMU support, and to allow for adding arch- specific hooks without stubs. KVM x86 is expected to be the only KVM architecture to support a mediated PMU in the near future (e.g. arm64 is trending toward a partitioned PMU implementation), and KVM x86 will select PERF_GUEST_MEDIATED_PMU unconditionally, i.e. won't need stubs. Immediately select PERF_GUEST_MEDIATED_PMU when KVM x86 is enabled so that all paths are compile tested. Full KVM support is on its way... [sean: add kconfig and WARNing, rewrite changelog, swizzle patch ordering] Suggested-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Mingwei Zhang <mizhang@google.com> Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Xudong Hao <xudong.hao@intel.com> Link: https://patch.msgid.link/20251206001720.468579-5-seanjc@google.com
2025-12-17arm64: dts: nuvoton: npcm845: Minor whitespace cleanupKrzysztof Kozlowski1-2/+2
The DTS code coding style expects exactly one space around '=' character. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250819131725.86770-4-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2025-12-17ARM: dts: aspeed: bletchley: Fix ADC vref property namesCosmo Chou1-2/+2
Replace non-functional 'vref' with 'aspeed,int-vref-microvolt' using the default 2.5V that the driver was already applying. Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-17ARM: dts: aspeed: bletchley: Remove unused i2c13 propertyCosmo Chou1-1/+0
Remove 'aspeed,hw-timeout-ms' property which is not supported by the driver and causes dt-schema warnings. Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-17ARM: dts: aspeed: bletchley: Remove unused pca9539 propertiesCosmo Chou1-12/+0
Remove unused #address-cells and #size-cells properties from pca9539 nodes to fix dt-schema warnings. Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-17ARM: dts: aspeed: bletchley: Fix SPI GPIO property namesCosmo Chou1-3/+3
Update SPI GPIO properties to use "-gpios" suffix: - gpio-sck -> sck-gpios - gpio-mosi -> mosi-gpios - gpio-miso -> miso-gpios Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-17ARM: dts: aspeed: bletchley: Use generic node namesCosmo Chou1-28/+49
Use generic node names to fix dt-schema warnings: - spi1_gpio: rename to generic "spi" node name - LED nodes: rename to led-N and move names to label properties - GPIO key nodes: add "-switch" suffix to node names Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
2025-12-17Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds3-13/+40
Pull bpf fixes from Alexei Starovoitov: - Fix BPF builds due to -fms-extensions. selftests (Alexei Starovoitov), bpftool (Quentin Monnet). - Fix build of net/smc when CONFIG_BPF_SYSCALL=y, but CONFIG_BPF_JIT=n (Geert Uytterhoeven) - Fix livepatch/BPF interaction and support reliable unwinding through BPF stack frames (Josh Poimboeuf) - Do not audit capability check in arm64 JIT (Ondrej Mosnacek) - Fix truncated dmabuf BPF iterator reads (T.J. Mercier) - Fix verifier assumptions of bpf_d_path's output buffer (Shuran Liu) - Fix warnings in libbpf when built with -Wdiscarded-qualifiers under C23 (Mikhail Gavrilov) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: add regression test for bpf_d_path() bpf: Fix verifier assumptions of bpf_d_path's output buffer selftests/bpf: Add test for truncated dmabuf_iter reads bpf: Fix truncated dmabuf iterator reads x86/unwind/orc: Support reliable unwinding through BPF stack frames bpf: Add bpf_has_frame_pointer() bpf, arm64: Do not audit capability check in do_jit() libbpf: Fix -Wdiscarded-qualifiers under C23 bpftool: Fix build warnings due to MS extensions net: smc: SMC_HS_CTRL_BPF should depend on BPF_JIT selftests/bpf: Add -fms-extensions to bpf build flags
2025-12-17arm64: dts: qcom: Add dts for Medion SPRCHRGD 14 S1Georg Gottleuber2-0/+1517
Initial support for the Medion SPRCHRGD 14 S1, which is based on the Qualcomm Snapdragon X Elite SoC (X1E78100). Working: * Touchpad * Keyboard * eDP * NVMe * USB Type-C port * USB-C DP altmode * HDMI-A port * WiFi * Bluetooth * GPU * Video decoding * USB Type-A * Audio, speakers, microphones - 4x speakers. - 2x dmic - headset * Camera * Fingerprint reader Co-developed-by: Srinivas Kandagatla <srini@kernel.org> Signed-off-by: Srinivas Kandagatla <srini@kernel.org> Co-developed-by: Ettore Chimenti <ettore.chimenti@linaro.org> Signed-off-by: Ettore Chimenti <ettore.chimenti@linaro.org> Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251204155212.230058-6-ggo@tuxedocomputers.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: x1e80100: Add crypto engineHarshal Dev1-0/+26
On X Elite, there is a crypto engine IP block similar to ones found on SM8x50 platforms. Describe the crypto engine and its BAM. Tested-by: Wenjia Zhang <wenjia.zhang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251211-crypto_dt_node_x1e80100-v6-1-03830ed53352@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: sm8650: Fix compile warnings in USB controller nodeKrishna Kurapati1-3/+0
With W=1, the following error comes up: Warning (avoid_unnecessary_addr_size): /soc@0/usb@a600000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property This is because the child node being removed during flattening and moving to latest bindings. Fixes: 77e1f16b9302 ("arm64: dts: qcom: sm8650: Flatten the USB nodes") Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251203144856.2711440-3-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: sm8550: Fix compile warnings in USB controller nodeKrishna Kurapati1-2/+0
With W=1, the following error comes up: Warning (avoid_unnecessary_addr_size): /soc@0/usb@a600000: unnecessary #address-cells/#size-cells without "ranges", "dma-ranges" or child "reg" or "ranges" property This is because the child node being removed during flattening and moving to latest bindings. Fixes: 33450878adfc ("arm64: dts: qcom: sm8550: Flatten the USB nodes") Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251203144856.2711440-2-krishna.kurapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: sc8280xp: Add missing VDD_MXC linksKonrad Dybcio1-4/+12
To make sure that power rail is voted for, wire it up to its consumers. Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20251202-topic-8280_mxc-v2-3-46cdf47a829e@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts qcom: sdm845-oneplus-enchilada: Specify panel name within the ↵David Heidelberg1-2/+2
compatible sofef00 is name of the DDIC, it doesn't contain name of the panel used. The DDIC is also paired with other panels, so make clear which panel is used. New device-tree will work with old driver as expected, due to secondary compatible. Cosmetic: sort the properties in the node. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://lore.kernel.org/r/20251204-sofef00-rebuild-v4-1-7f6e030ae5b7@ixit.cz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-17arm64: dts: qcom: talos: Correct UFS clocks orderingPradeep P V K1-2/+2
The current UFS clocks does not align with their respective names, causing the ref_clk to be set to an incorrect frequency as below, which results in command timeouts. ufshcd-qcom 1d84000.ufshc: invalid ref_clk setting = 300000000 This commit fixes the issue by properly reordering the UFS clocks to match their names. Fixes: ea172f61f4fd ("arm64: dts: qcom: qcs615: Fix up UFS clocks") Cc: stable@vger.kernel.org Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251126131146.16146-1-pradeep.pragallapati@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-16efi: Support EDID informationThomas Zimmermann1-9/+9
In the EFI config table, rename LINUX_EFI_SCREEN_INFO_TABLE_GUID to LINUX_EFI_PRIMARY_DISPLAY_TABLE_GUID. Read sysfb_primary_display from the entry. In addition to the screen_info, the entry now also contains EDID information. In libstub, replace struct screen_info with struct sysfb_display_info from the kernel's sysfb_primary_display and rename functions accordingly. Transfer it to the runtime kernel using the kernel's global state or the LINUX_EFI_PRIMARY_DISPLAY_TABLE_GUID config-table entry. With CONFIG_FIRMWARE_EDID=y, libstub now transfers the GOP device's EDID information to the kernel. If CONFIG_FIRMWARE_EDID=n, EDID information is disabled. Make the Kconfig symbol CONFIG_FIRMWARE_EDID available with EFI. Setting the value to 'n' disables EDID support. Also rename screen_info.c to primary_display.c and adapt the contained comment according to the changes. Link: https://lore.kernel.org/all/20251126160854.553077-8-tzimmermann@suse.de/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> [ardb: depend on EFI_GENERIC_STUB not EFI, fix conflicts after dropping the preceding patch from the series] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-12-16perf/x86/intel/cstate: Add Diamond Rapids supportZide Chen1-0/+1
From a C-state residency profiling perspective, Diamond Rapids is similar to SRF and GNR, supporting core C1/C6, module C6, and package C2/C6 residency counters. Similar to CWF, the C1E residency can be accessed via PMT only. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251215182520.115822-3-zide.chen@intel.com
2025-12-16perf/x86/intel/cstate: Add Nova Lake supportZide Chen1-7/+22
Similar to Lunar Lake and Panther Lake, Nova Lake supports CC1/CC6/CC7 and PC2/PC6/PC10 residency counters; it also adds support for MC6. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251215182520.115822-2-zide.chen@intel.com
2025-12-16perf/x86/intel/cstate: Add Wildcat Lake supportZide Chen1-6/+8
Wildcat Lake (WCL) is a low-power variant of Panther Lake. From a C-state profiling perspective, it supports the same residency counters: CC1/CC6/CC7 and PC2/PC6/PC10. Signed-off-by: Zide Chen <zide.chen@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://patch.msgid.link/20251215182520.115822-1-zide.chen@intel.com
2025-12-16sysfb: Move edid_info into sysfb_primary_displayThomas Zimmermann1-5/+1
Move x86's edid_info into sysfb_primary_display as a new field named edid. Adapt all users. An instance of edid_info has only been defined on x86. With the move into sysfb_primary_display, it becomes available on all architectures. Therefore remove this contraint from CONFIG_FIRMWARE_EDID. x86 fills the EDID data from boot_params.edid_info. DRM drivers pick up the raw data and make it available to DRM clients. Replace the drivers' references to edid_info and instead use the sysfb_display_info as passed from sysfb. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-12-16sysfb: Replace screen_info with sysfb_primary_displayThomas Zimmermann7-17/+22
Replace the global screen_info with sysfb_primary_display of type struct sysfb_display_info. Adapt all users of screen_info. Instances of screen_info are defined for x86, loongarch and EFI, with only one instance compiled into a specific build. Replace all of them with sysfb_primary_display. All existing users of screen_info are updated by pointing them to sysfb_primary_display.screen instead. This introduces some churn to the code, but has no impact on functionality. Boot parameters and EFI config tables are unchanged. They transfer screen_info as before. The logic in EFI's alloc_screen_info() changes slightly, as it now returns the screen field of sysfb_primary_display. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/ Reviewed-by: Richard Lyu <richard.lyu@suse.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-12-16arm64: dts: apple: t8103,t60xx,t8112: Add SMC RTC nodeSven Peter4-0/+24
The System Manager Controller of all M1/M2 SoCs supports the RTC sub-device. Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: James Calligeros <jcalligeros99@gmail.com> Link: https://patch.msgid.link/20251215-macsmc-subdevs-v6-6-0518cb5f28ae@gmail.com Signed-off-by: Sven Peter <sven@kernel.org>
2025-12-16arm64: dts: ti: am62p-verdin: Fix SD regulator startup delayFrancesco Dolcini1-1/+1
The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20251209084126.33282-1-francesco@dolcini.it Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-16arm64: dts: ti: k3-am69-aquila-clover: Fix USB-C Sink PDOFrancesco Dolcini1-2/+2
Change USB-C Sink PDO and the amount of power that the device can sink to zero to maximize compatibility with other USB peers (the Aquila Clover Board is not sinking any current, it is self powered). Fixes: 9f748a6177e1 ("arm64: dts: ti: am69-aquila: Add Clover") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20251204134220.129304-3-francesco@dolcini.it Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-16arm64: dts: ti: k3-am69-aquila-dev: Fix USB-C Sink PDOFrancesco Dolcini1-2/+2
Change USB-C Sink PDO and the amount of power that the device can sink to zero to maximize compatibility with other USB peers (the Aquila Development Board is not sinking any current, it is self powered). Fixes: 39ac6623b1d8 ("arm64: dts: ti: Add Aquila AM69 Support") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20251204134220.129304-2-francesco@dolcini.it Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-16arm64: dts: ti: k3-am62(a)-phycore-som: Add bootphase tag to phy_gmii_selWadim Egorov2-0/+8
Add the bootph-all property to the phy_gmii_sel node to ensure it is available during all boot phases. This is required when the bootloader is getting booted via network. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251124160548.2273931-1-w.egorov@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-16arm64: dts: ti: k3-am62a-phycore-som: Add bootphase tag to cpsw_mac_sysconDaniel Schultz1-0/+4
Add the "bootph-all" property to cpsw_mac_syscon. This fuse region contains the internal MAC address. Without this syscon node enabled, this interface will get a random MAC during network boot. This is problematic because the AM62Ax network boot is using BOOTP protocol for some binaries and this protocol does not support dynamic lease expiration. Therefore, the DHCP server can run out of free IP addresses. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251124090842.3377294-2-d.schultz@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-16arm64: dts: ti: k3-am62-phycore-som: Add bootphase tag to cpsw_mac_sysconDaniel Schultz1-0/+4
Add the "bootph-all" boot phase property to cpsw_mac_syscon. This fuse region contains the internal MAC address. Without this syscon node enabled, this interface will get a random MAC during network boot. This is problematic because the AM62x network boot is using BOOTP protocol for some binaries and this protocol does not support dynamic lease expiration. Therefore, the DHCP server can run out of free IP addresses. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Link: https://patch.msgid.link/20251124090842.3377294-1-d.schultz@phytec.de Signed-off-by: Nishanth Menon <nm@ti.com>
2025-12-16arm64: dts: exynos: gs101: remove syscon compatible from pmu nodePeter Griffin1-1/+1
Since commit ba5095ebbc7a ("mfd: syscon: Allow syscon nodes without a "syscon" compatible") it is possible to register a regmap without the syscon compatible in the node. As mentioned in that commit, it's not correct to claim we are compatible with syscon, as a MMIO regmap created by syscon won't work. Removing the syscon compatible means syscon driver won't ever create a mmio regmap. Note this isn't usually an issue today as exynos-pmu runs at an early initcall so the custom regmap will have been registered first. However changes proposed in [1] will bring -EPROBE_DEFER support to syscon allowing this mechanism to be more robust, especially in highly modularized systems. Technically this is a ABI break but no other platforms are affected. Additionally (with the benefit of hindsight) a MMIO syscon has never worked for PMU register writes, thus the ABI break is justified. Link: https://lore.kernel.org/lkml/aQdHmrchkmOr34r3@stanley.mountain/ [1] Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Link: https://patch.msgid.link/20251114-remove-pmu-syscon-compat-v2-2-9496e8c496c7@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2025-12-16x86/xen: Fix sparse warning in enlighten_pv.cJuergen Gross1-1/+1
The sparse tool issues a warning for arch/x76/xen/enlighten_pv.c: arch/x86/xen/enlighten_pv.c:120:9: sparse: sparse: incorrect type in initializer (different address spaces) expected void const [noderef] __percpu *__vpp_verify got bool * This is due to the percpu variable xen_in_preemptible_hcall being exported via EXPORT_SYMBOL_GPL() instead of EXPORT_PER_CPU_SYMBOL_GPL(). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512140856.Ic6FetG6-lkp@intel.com/ Fixes: fdfd811ddde3 ("x86/xen: allow privcmd hypercalls to be preempted") Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <20251215115112.15072-1-jgross@suse.com>
2025-12-16arm64: dts: exynos: gs101: add TRNG nodeTudor Ambarus1-0/+9
Define the TRNG node. GS101 TRNG works well with the current Exynos850 TRNG support. Specify the Google specific compatible in front of the Exynos one. Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Link: https://patch.msgid.link/20251024-gs101-trng-v3-2-5d3403738f39@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2025-12-16arm64: dts: toshiba: tmpv7708: Align node names with DT bindingsKrzysztof Kozlowski2-3/+3
DT bindings expect node names to follow certain pattern, dtbs_check warnings: tmpv7708-rm-mbrc.dtb: pmux@24190000 (toshiba,tmpv7708-pinctrl): 'pwm_mux' does not match any of the regexes: '-pins$', '^pinctrl-[0-9]+$' tmpv7708-rm-mbrc.dtb pmux@24190000 (toshiba,tmpv7708-pinctrl): $nodename:0: 'pmux@24190000' does not match '^(pinctrl|pinmux)(@[0-9a-f]+)?$' tmpv7708-rm-mbrc.dtb: wdt@28330000 (toshiba,visconti-wdt): $nodename:0: 'wdt@28330000' does not match '^(timer|watchdog)(@.*|-([0-9]|[1-9][0-9]+))?$' Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba> Link: https://patch.msgid.link/20251022133616.74492-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2025-12-16arm64: dts: renesas: r9a09g087: Add ICU supportCosmin Tanislav1-0/+73
The Renesas RZ/N2H (R9A09G087) SoC has an Interrupt Controller (ICU) block that routes external interrupts to the GIC's SPIs, with the ability of level-translation, and can also produce software and aggregate error interrupts. Add support for it. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251201112933.488801-5-cosmin-gabriel.tanislav.xa@renesas.com
2025-12-16arm64: dts: renesas: r9a09g077: Add ICU supportCosmin Tanislav1-0/+73
The Renesas RZ/T2H (R9A09G077) SoC has an Interrupt Controller (ICU) block that routes external interrupts to the GIC's SPIs, with the ability of level-translation, and can also produce software and aggregate error interrupts. Add support for it. Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251201112933.488801-4-cosmin-gabriel.tanislav.xa@renesas.com