summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor NVLDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Novalake according to the latest NVL perfmon events. The 4 PRECISE_OMR events (0xd4) are broken on Arcticwolf and would be removed from upcoming released event list, so delete them from event constraints and extra_regs array accordingly. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-10-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints for PTLDapeng Mi
Update perf hard-coded event constraints for Pantherlake according to the latest PTL perfmon events (V1.05). PTL has almost same perf event list as LNL except some PEBS event constraints of E-core (exactly same on P-core). Define intel_dkt_pebs_event_constraints[] to reflect the PTL E-core specific PEBS event constraints. PTL perfmon events: https://github.com/intel/perfmon/blob/main/PTL/events/pantherlake_cougarcove_core.json https://github.com/intel/perfmon/blob/main/PTL/events/pantherlake_darkmont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-9-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor ARLDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Arrowlake according to the latest ARL perfmon events (V1.17). ARL shares almost same event constraints and extra MSR configuration with LNL except 2 differences. - ARL P-core has different extra MSR value for OCR.DEMAND_DATA_RD.L3_MISS and OCR.DEMAND_RFO.L3_MISS. So introduce arl_lnc_hw_cache_extra_regs[] to reflect the difference. - ARL-H has extra LPE cores which use crestmont architectures. Add crestmont specific event constraints and hw_cache_extra_regs[] for LPE cores. ARL perfmon events: https://github.com/intel/perfmon/blob/main/ARL/events/arrowlake_lioncove_core.json https://github.com/intel/perfmon/blob/main/ARL/events/arrowlake_skymont_core.json https://github.com/intel/perfmon/blob/main/ARL/events/arrowlake_crestmont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-8-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor LNLDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Lunarlake according to the latest LNL perfmon events (V1.22). LNL introduces new extra register values for the OCR L3 cache events, so introduce lnc_hw_cache_extra_regs[] and skt_hw_cache_extra_regs[] to reflect the changes. LNL perfmon events: https://github.com/intel/perfmon/blob/main/LNL/events/lunarlake_lioncove_core.json https://github.com/intel/perfmon/blob/main/LNL/events/lunarlake_skymont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-7-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor MTLDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Meteor Lake according to the latest MTL perfmon events (V1.21). MTL P-core (redwoodcove) inherits same perf events list from previous generation (Goldencove), but the E-core (Crestmont) brings some difference on the perf event list comparing with Gracemont. So apply the changes for Crestmont core. MTL perfmon events: https://github.com/intel/perfmon/blob/main/MTL/events/meteorlake_redwoodcove_core.json https://github.com/intel/perfmon/blob/main/MTL/events/meteorlake_crestmont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-6-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor ADLDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Alderlake according to the latest ADL perfmon events (V1.39). One important note is that ADL has differences on the L3/node related OCR events although it shares same uarch with SPR server, e.g., ADL has different extra MSR values and no node events. So some variants of structures and functions are introduced to reflect these differences, like adl_glc_hw_cache_event_ids[], adl_glc_hw_cache_extra_regs[] and intel_pmu_init_glc_hybrid(), etc. Please note these changes would temporarily impact other platforms like MTL/ARL-U which shares hard-coded event structures, but it would be fixed soon in subsequent patches. ADL perfmon events: https://github.com/intel/perfmon/blob/main/ADL/events/alderlake_goldencove_core.json https://github.com/intel/perfmon/blob/main/ADL/events/alderlake_gracemont_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-5-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints for DMRDapeng Mi
Add missed event constraint for 0x0200 event and add comments to show the event names in pnc_hw_cache_extra_regs[]. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-4-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor SPRDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Sapphire rapids according to the latest SPR perfmon events (v1.39). Emerald Rapids (EMR) and Granite Rapids (GNR) share exactly same event constraints and extra MSR values with SPR. No extra changes are needed for EMR and GNR. Please note the change could temporarily impact other platforms which share the hard coded data structures, but it would be fixed in subsequent patches soon. SPR perfmon events: https://github.com/intel/perfmon/blob/main/SPR/events/sapphirerapids_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-3-dapeng1.mi@linux.intel.com
2026-05-19perf/x86/intel: Update event constraints and cache_extra_regsfor ICXDapeng Mi
Update perf hard-coded event constraints and cache_extra_regs[] for Icelake server according to the latest ICX perfmon events (v1.30). Since the value of cache extra registers differs with previous generations, introduce new snc_hw_cache_extra_regs[] to represent the value of extra registers on ICX. ICX perfmon events: https://github.com/intel/perfmon/blob/main/ICX/events/icelakex_core.json Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260515061143.338553-2-dapeng1.mi@linux.intel.com
2026-05-19locking/rtmutex: Annotate API and implementationBart Van Assche
Enable context analysis for struct rt_mutex and annotate all functions that accept a struct rt_mutex pointer. In the __rt_mutex_lock_common() callers, instead of adding the __no_context_analysis annotation, emit a runtime warning if the __rt_mutex_lock_common() return value is not zero and add an __acquire() statement. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260508174520.1416285-1-bvanassche@acm.org
2026-05-19drm/imagination: Add support for trace pointsAlexandru Dadu
Add support for workload submission trace points. Co-developed-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Donald Robson <donald.robson@imgtec.com> Signed-off-by: Alexandru Dadu <alexandru.dadu@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260513-b4-pvr-trace-points-v1-1-81222d1a4c99@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19iommu: arm-smmu-qcom: Ensure smmu is powered up in set_ttbr0_cfgAnna Maniscalco
arm_smmu_write_context_bank() assumes it is being called with RPM active, but it turns out that is not guaranteed in the path from qcom_adreno_smmu_set_ttbr0_cfg(), so it's possible for the register writes to get lost when configuring the context bank while the GPU is idle, leading to page faults later. Add the RPM calls here to make sure the SMMU is active before we touch it. Signed-off-by: Anna Maniscalco <anna.maniscalco2000@gmail.com> Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19drm/imagination: Access FW initialised state with READ/WRITE_ONCEBrajesh Gupta
Update FW initialised state shared resource access with READ/WRITE_ONCE to prevent following: - Non-atomic access to variable in multi-thread/CPU case. - Merge successive loads from the same variable. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-4-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19drm/imagination: Rename FW booted to FW initialisedBrajesh Gupta
Rename the variable from 'booted' to 'initialised' to align with the driver's expectations and state, indicating that FW boot initialisation is complete and the firmware is fully initialised. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-3-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19drm/imagination: Don't timeout job if its fence has been signaledBrajesh Gupta
Verify the job’s fence in the timeout handler; if the firmware has since signaled completion, then report NO HANG. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-2-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19drm/imagination: Populate FW common context ID before passing to the FWBrajesh Gupta
Initialise the context ID for the FW common context correctly by moving the context allocation earlier. Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://patch.msgid.link/20260519-b4-context_reset-v2-1-931018a7131d@imgtec.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2026-05-19sched/topology: Allow multiple domains to claim sched_domain_sharedK Prateek Nayak
Recent optimizations of sd->shared assignment moved to allocating a single instance of per-CPU sched_domain_shared objects per s_data. Recent optimizations to select_idle_capacity() moved the sd->shared assignments to "sd_asym" domain when ASYM_CPUCAPACITY is detected but cache-aware scheduling mandates the presence of "sd_llc_shared" to compute and cache per-LLC statistics. Use an "alloc_flags" union in sched_domain_shared to claim a sched_domain_shared object per sched_domain. Allocation starts searching for an available / matching sched_domain_shared instance from the first CPU of sched_domain_span(sd) (sd can be sd_llc, or sd_asym). If the shared object is claimed by another domain, the instance corresponding to next CPU in the domain span is explored until a matching / available instance is found. In case of a single CPU in sched_domain_span(), the domain will be degenerated and a temporary overlap of ->shared objects across different domains is acceptable. "alloc_flags" forms a union with "nr_idle_scan" and the stale flags are left as is when the sd->shared is published. The expectation is for the first load balancing instance to correct the value just like the current behavior, except the initial value is no longer 0. Originally-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: Andrea Righi <arighi@nvidia.com>
2026-05-19ipmi: Use LIST_HEAD() to initialize on stack list headJisheng Zhang
Use LIST_HEAD to initialize on stack list head. No intentional functional impact. Change generated with below coccinelle script: @@ identifier name; @@ - struct list_head name; + LIST_HEAD(name); ... when != name - INIT_LIST_HEAD(&name); Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Message-ID: <20260519055722.13161-1-jszhang@kernel.org> Signed-off-by: Corey Minyard <corey@minyard.net>
2026-05-19ipmi:kcs: Reduce the number of retriesCorey Minyard
The retry count was initially set to 10, which with the 5 second timeouts give 55 seconds to fail a message. The IPMI spec specifies the 5 second timeout, and it specifies retries for KCS but does not specify a number. 55 seconds is a long time, so reduce retries to 2. It matches the default in the BT state machine. This is 15 seconds, then, which is still a long time, but more reasonable. Signed-off-by: Corey Minyard <corey@minyard.net>
2026-05-19drm/i915/selftests: Run vma tests only if current->mm is presentKrzysztof Karas
This set of tests require userspace memory to map objects, so run them only if this that memory is available. Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260508080214.1979686-3-krzysztof.karas@intel.com
2026-05-19drm/i915/selftests: Prevent userspace mapping invalidationKrzysztof Karas
Migration testing in i915 assumes current task's address space to allocate new userspace mapping and uses it without registering real user for that address space in mm_struct. On single NUMA node setups PCI probe executes in the same context as userspace process calling the test (i915_selftest from IGT), but when multiple nodes are available, the PCI code puts probe into a kernel workqueue. This switches execution to a kworker, which does not have its own address space in userspace and must borrow such memory from another process, so "current->active_mm" is unknown at the start of the test. It was observed that mm->mm_users would occasionally be 0 or drop to 0 during the test due to short delay between scheduling and executing work in forked process, which reaped userspace mappings, further leading to failures upon reading from userland memory. Prevent this by adding a PID parameter to a trusted task, so its mm_struct may be used if needed. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14204 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260508080214.1979686-2-krzysztof.karas@intel.com
2026-05-19arm64: panic from init_IRQ if IRQ handler stacks cannot be allocatedOsama Abdelkader
init_irq_stacks() and init_irq_scs() may fail when arch_alloc_vmap_stack or scs_alloc return NULL. Return -ENOMEM from both and call panic() once from init_IRQ(), covering per-CPU IRQ stacks and shadow IRQ stacks consistently. Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19arm64: smp: Do not mark secondary CPUs possible under nosmpPengjie Zhang
Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs. smp_prepare_cpus() already treats this as a UP-mandated boot and returns before marking secondary CPUs present. However, smp_init_cpus() may still enumerate firmware-described secondary CPUs and mark them possible before that point. Avoid marking secondary CPUs possible when nosmp/maxcpus=0 is in effect, so that cpu_possible_mask reflects the nosmp boot policy for this boot. Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19arm64: proton-pack: use sysfs_emit in sysfs show functionsThorsten Blum
Replace sprintf() with sysfs_emit() in sysfs show functions, which is preferred for formatting sysfs output because it provides safer bounds checking. While the current code only emits fixed strings that fit easily within PAGE_SIZE, use sysfs_emit() to follow secure coding best practices. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA bufferErni Sri Satya Vennela
In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp() re-reads the same field from the same DMA buffer for test_bit() and pointer arithmetic. DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation. Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), and passing the validated value as a parameter to mana_hwc_handle_resp(). Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Link: https://patch.msgid.link/20260514194156.466823-1-ernis@linux.microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19iommu/arm-smmu-qcom: Add glymur MDSS to ACTLR client tableLokanadha M R
Add qcom,glymur-mdss to the qcom_smmu_actlr_client_of_match[] table to configure the SMMU-500 context bank for the display subsystem (MDSS) on the Glymur platform. The settings disable the next-page prefetcher while keeping macro TLB caching enabled. Without this entry, qcom_smmu_set_actlr_dev() finds no match for the glymur MDSS device and leaves the context bank ACTLR at its reset value. Signed-off-by: Lokanadha M R <lokanadha.r@oss.qualcomm.com> Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19arm64: errata: Reformat table for IDsRobin Murphy
We have some inconsistency where multiple errata for the same component share the same Kconfig workaround; some are one ID per line, some are smooshed together, and some are entirely separate entries. Standardise on the single entry, one ID per line format so that things render nice and consistently in the HTML docs, and it's simple and clear to add new IDs to existing workarounds without churning the table too much. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19kselftest/arm64: Add tests for POR_EL0 save/reset/restoreKevin Brodsky
POR_EL0 is expected to be: - Saved in the poe_context record - Reset to POR_EL0_INIT when invoking the signal handler - Restored from poe_context when returning from the signal handler Add a new test, poe_restore, to check that the save/reset/restore mechanism is working as intended. See commit 2e8a1acea859 ("arm64: signal: Improve POR_EL0 handling to avoid uaccess failures") for more details. This commit did not handle the case where poe_context is missing correctly. This was recently fixed; add a new test, poe_missing_poe_context, to check this case. Note: td->pass is only set to true at the very end, as an unexpected signal may occur in case of failure (especially in poe_missing_poe_context if POR_EL0 is restored to an invalid value). Failures are tracked with a global, failed_check. Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19kselftest/arm64: Move/add POE helpers to test_signals_utils.hKevin Brodsky
In preparation to adding further POE signal tests, move get_por_el0() to test_signals_utils.h and add set_por_el0(). Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19kselftest/arm64: Add POE as a feature in the signal testsKevin Brodsky
Add the POE feature to the signal tests framework, to allow tests to require it. Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19selftests/mm: Fix resv_sz when parsing arm64 signal frameKevin Brodsky
get_header() wants the size of the reserved area in struct sigcontext, but instead we pass it the size of the entire struct. This could in theory result in an out-of-bounds read (if the signal frame is malformed). Fix this using one of the existing macros from tools/testing/selftests/arm64/signal/testcases/testcases.h. This issue was reported by Sashiko on a patch that copied this portion of the code. Link: https://sashiko.dev/#/patchset/20260421144252.1440365-1-kevin.brodsky%40arm.com Fixes: f5b5ea51f78f ("selftests: mm: make protection_keys test work on arm64") Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19MAINTAINERS: Hand over phy-zynqmp to Tomi ValkeinenLaurent Pinchart
I volunteered to maintain the phy-zynqmp driver as part of my work on the ZynqMP DPSUB driver. Now that Tomi has taken over the DPSUB, it makes sense for him to handle the phy-zynqmp driver as well. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260519082253.40142-1-laurent.pinchart@ideasonboard.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19arm64/mm: Replace BUG_ON() with VM_WARN_ON_ONCE()Anshuman Khandual
Avoid BUG_ON() while checking for inconsistent page table state conditions and instead replace them with VM_WARN_ON_ONCE(). Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: David Hildenbrand <david@kernel.org> Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Acked-by: David Hildenbrand (Arm) <david@kernel.org> Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19i2c: smbus: fix a potential uninitialization bugWenwen Wang
In i2c_smbus_xfer_emulated(), there are two buffers: msgbuf0 and msgbuf1, which are used to save a series of messages, as mentioned in the comment. According to the value of the variable 'size', msgbuf0 is initialized to various values. In contrast, msgbuf1 is left uninitialized until the function i2c_transfer() is invoked. However, msgbuf1 is not always initialized on all possible execution paths (implementation) of i2c_transfer(). Thus, it is possible that msgbuf1 may still be uninitialized even after the invocation of the function i2c_transfer(), especially when the return value of i2c_transfer() is not checked properly. In the following execution, the uninitialized msgbuf1 will be used, such as for security checks. Since uninitialized values can be random and arbitrary, this will cause undefined behaviors or even check bypass. For example, it is expected that if the value of 'size' is I2C_SMBUS_BLOCK_PROC_CALL, the value of data->block[0] should not be larger than I2C_SMBUS_BLOCK_MAX. This patch initializes the first byte of msgbuf1 with 0 to avoid such undefined behaviors or security issues. Signed-off-by: Wenwen Wang <wang6495@umn.edu> [wsa: reworded commit message a little] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-05-19platform/x86/amd: hfi: Support for ranking table versionsKrishnamoorthi M
Add changes to support new ranking table version. Version 2 of the heterogeneous ranking table provides static CPU rankings. Version 3 adds dynamic ranking table support on newer AMD platforms. These changes ensure that platforms still reporting version 2 continue to function with the existing static ranking path, avoiding regressions on older hardware that does not supply a dynamic ranking table. Signed-off-by: Krishnamoorthi M <krishnamoorthi.m@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20260507190926.1211726-1-krishnamoorthi.m@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-05-19dt-bindings: arm-smmu: qcom: Add Hawi compatible for Application processorMukesh Ojha
Commit 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC") was intended for the APSS SMMU but was mistakenly placed under the Adreno GPU SMMU section. Since that compatible is also valid for the Hawi GPU SMMU, keep that commit as-is and add proper documentation for the Hawi APSS SMMU here. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19arm64/daifflags: Make local_daif_*() helpers __always_inlineLeonardo Bras
Make sure those helpers are always inlined and instrumentation safe. Suggested-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Leonardo Bras <leo.bras@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19Merge branch 'net-dsa-mt7530-assorted-fixes'Paolo Abeni
Daniel Golle says: ==================== net: dsa: mt7530: assorted fixes A batch of small, independent fixes for the MediaTek MT7530 family DSA driver, addressing long-standing correctness issues that surface on hardware with bridge VLAN filtering enabled, on link-local frame reception, and during bridge join/leave transitions. ==================== Link: https://patch.msgid.link/cover.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19net: dsa: mt7530: untag VLAN-aware bridge PVIDEdward Parker
With bridge VLAN filtering enabled on a port configured as untagged member of the bridge PVID, ingress untagged frames do not reach the corresponding bridge VLAN upper interface (br-lan.<vid>). ARP and similar traffic is visible on the physical port but not delivered to the VLAN sub-interface. The MT7530/MT7531 forwards frames to the CPU port with the user port's PVID tag applied even when the frame ingressed untagged on the wire, because the CPU port is set to MT7530_VLAN_EG_CONSISTENT and is a tagged member of the VLAN entry created for the bridge VLAN. The DSA core then sees a hwaccel-tagged frame whose VID matches the port's PVID, which the bridge does not treat as the untagged-on-the-wire frame that the user expects. Set ds->untag_vlan_aware_bridge_pvid in the mt7530 and mt7531 setup paths so the DSA core strips that hwaccel tag in software when the parsed VID matches the bridge port's PVID, restoring the on-the-wire frame as the bridge expects to see it. Link: https://github.com/openwrt/openwrt/issues/18576 Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: Edward Parker <edward@topnotchit.com> [daniel@makrotopia.org: improve commit message] Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/85d25ea1b26d3c907f815649f2e0bde6560282a3.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19net: dsa: mt7530: fix CPU port VLAN not being reset to unawareDaniel Golle
After a VLAN-aware bridge is destroyed, creating any VLAN-unaware bridge loses all connectivity. The VID 0 VLAN table entry used by VLAN-unaware ports in FALLBACK mode gets corrupted during VLAN-aware operation: mt7530_hw_vlan_add() overwrites its EG_CON flag with VTAG_EN and bridge teardown removes ports from its PORT_MEM. The cleanup code that should restore it never runs because the current port's dp->vlan_filtering flag is still true when checked (DSA updates it only after the driver callback returns). Even when restored, the deferred VLAN deletion events from the switchdev workqueue can corrupt VID 0 again after the restoration. Skip the current port in the all_user_ports_removed check, call mt7530_setup_vlan0() to restore the VID 0 entry, and protect VID 0 from being modified by bridge VLAN operations in port_vlan_add and port_vlan_del since it is managed exclusively by mt7530_setup_vlan0(). Remove the CPU port PCR and PVC register writes which were clobbering PORT_VLAN mode and VLAN_ATTR with wrong values. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/da8bdaf08b2427a9057e6cb33e26d41f8a8d5000.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19net: dsa: mt7530: preserve VLAN tags on trapped link-local framesDaniel Golle
The BPC, RGAC1 and RGAC2 registers control the handling of link-local frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are correctly trapped to the CPU port, but the egress VLAN tag attribute was set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any VLAN tags from trapped frames before they reach the CPU. This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer Delay Requests) to arrive at the CPU without their VLAN tag, so they are delivered to the base network interface instead of the VLAN sub-interface. The DSA local_termination selftest confirms this: all link-local protocol tests on VLAN upper interfaces fail. Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default) so that the switch does not modify VLAN tags in trapped frames. This way VLAN-tagged frames retain their original tag and are delivered to the correct VLAN sub-interface, matching the behavior of non-trapped frames which pass through without VLAN tag modification. Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://patch.msgid.link/891e0cd34db2a5fe20ceb73283a81fb5f71427ca.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19net: dsa: mt7530: fix FDB entries not aging out with short timeoutDaniel Golle
The DSA forwarding selftests bridge_vlan_aware.sh and bridge_vlan_unaware.sh configure the bridge with ageing_time set to LOW_AGEING_TIME (1000 centiseconds, i.e. 10 seconds) and then run learning_test() in lib.sh, which expects a learned FDB entry to be removed after ageing_time + 10 seconds. On MT7530/MT7531 the entry persisted past the deadline and the "Found FDB record when should not" assertion failed. With msecs=10000, the algorithm in mt7530_set_ageing_time() finds AGE_CNT=0 and AGE_UNIT=9 as the first exact match (starting the search from tmp_age_count=0). The per-entry aging counter is initialized to AGE_CNT when a MAC address is learned, so with AGE_CNT=0 new entries start with a counter value of 0, which the hardware treats as "already aged" and never removes, effectively disabling aging. Fix this by starting the search from tmp_age_count=1 to ensure entries always have a non-zero initial aging counter. For a 10-second ageing time this yields AGE_CNT=1 and AGE_UNIT=4 instead: the timer ticks every 5 seconds and entries are removed after 2 ticks. Starting the search at AGE_CNT=1 raises the minimum representable ageing time from 1 to 2 seconds. Without bounds, a stale ageing_time of 1 second would now make the loop fall through without setting age_count and age_unit, leaving them uninitialized when written to the MT7530_AAC hardware register. Set ds->ageing_time_min and ds->ageing_time_max so the DSA core validates the range before the callback is invoked, and drop the now-redundant range check from mt7530_set_ageing_time(). Fixes: ea6d5c924e39 ("net: dsa: mt7530: support setting ageing time") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://patch.msgid.link/7788ded12dc07b1bce329ec35fa70f4b45f3f9b7.1778766629.git.daniel@makrotopia.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-19phy: ti: add PHY driver for TI DS125DF111 Dual-Channel RetimerIoana Ciornei
Add a generic PHY driver for the TI DS125DF111 Multi-Protocol Dual-Channel Retimer. The driver currently supports only 10G and 1G link speeds but it can easily extended to also cover other usecases. Since the available datasheet (https://www.ti.com/lit/gpn/DS125DF111) does not name the registers, the name for the macros were determined by their usage pattern. A PHY device is created for each of the two channels present on the retimer. This allows for independent configuration of the two channels. This capability is especially important on retimers which have more than 2 channels that can be, depending on the board design, connected in multiple different ways to the SerDes lanes. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20260518142026.3098496-4-ioana.ciornei@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19phy: ti: alphabetically sort Kconfig and MakefileIoana Ciornei
Sort alphabetically the entries in the Kconfig and Makefile files. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/20260518142026.3098496-3-ioana.ciornei@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19dt-bindings: phy: add PHY bindings for the TI DS125DF111 Retimer PHYIoana Ciornei
Add device tree binding for the TI DS125DF111 Retimer PHY. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20260518142026.3098496-2-ioana.ciornei@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19perf: qcom: Unify user-visible "Qualcomm" nameKrzysztof Kozlowski
Various names for Qualcomm as a company are used in user-visible config options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified "Qualcomm" so it will be easier for users to identify the options when for example running menuconfig. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19phy: rockchip: naneng-combphy: Consolidate SSC configurationShawn Lin
The PCIe SSC configuration for the RK3588 and RK3576 SoCs required additional tuning which is missing. When adding these same SSC configurations for both of these two SoCs, as well as upcoming platforms, it's obvious the SSC setup code was largely duplicated across the platform-specific configuration functions. This becomes harder to maintain as more platforms are added. So extract the common SSC logic into a shared helper function, rk_combphy_common_cfg_ssc(). This cleans up the per-platform drivers and centralizes the standard configuration as possible. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/1777251433-110466-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-05-19arm64/sysreg: Add HDBSS related register informationeillon
The ARM architecture added the HDBSS feature and descriptions of related registers (HDBSSBR/HDBSSPROD) in the DDI0601(ID121123) version, add them to Linux. Signed-off-by: eillon <yezhenyu2@huawei.com> Signed-off-by: Tian Zheng <zhengtian10@huawei.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-05-19kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning schemeViktor Jägersküpper
The package versioning scheme does not enable smooth upgrades from "rc" releases to the corresponding stable releases (e.g. 7.0.0-rc7 -> 7.0.0) because pacman considers that a downgrade due to the underscore in pkgver (e.g. 7.0.0_rc7), see e.g. vercmp(8) for an explanation of the package version comparison used by pacman. Package versions which are derived from said releases (e.g. built from git revisions) are similarly affected. Fix this by modifying pkgver in order to remove the hyphen from kernel versions containing "-rcN", where N is a non-negative integer. Acked-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260515215913.92481-1-viktor_jaegerskuepper@freenet.de Fixes: c8578539deba ("kbuild: add script and target to generate pacman package") Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-19modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()Hasan Basbunar
Several functions in scripts/mod/file2alias.c build the module alias string by repeatedly appending into a fixed-size on-stack buffer: char alias[256] = {}; ... sprintf(alias + strlen(alias), "%X,*", i); This pattern is unbounded and silently corrupts the stack when the formatted output exceeds the destination size. Two functions in this file are realistically reachable with input that overflows their buffer: 1. do_input_entry() appends across nine bitmap classes (evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING (0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the emission reaches ~3132 bytes — overflowing the 256-byte buffer by about 12x. include/linux/mod_devicetable.h declares storage for the full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"), so the worst case is reachable per the ABI. 2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per matched DMI field, up to 4 matches per dmi_system_id. Each substr is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584), and dmi_ascii_filter() copies it verbatim into the alias buffer without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes into alias[256], an 80-byte overflow. No driver in the current tree triggers either case — every in-tree INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely (1-3 bits), and no in-tree dmi_system_id has four maximally-long matches. The concern is defense-in-depth: both unbounded sprintf chains are silent stack-corruption primitives in a host build tool, and the buffer sizes have not been revisited since the corresponding code was first introduced. The other do_*_entry() handlers in this file (do_usb_entry, do_cpu_entry, do_typec_entry, ...) were audited and are bounded by their input field sizes (uint16 IDs, fixed-length keys); their alias buffers do not need this treatment. Reproduced under AddressSanitizer with a stand-alone harness mirroring do_input on a fully-populated keybit: ==18319==ERROR: AddressSanitizer: stack-buffer-overflow WRITE of size 2 at offset 288 in frame [32, 288) 'alias' #6 do_input poc.c:44 Stack-canary build: Abort trap: 6 (strlen(alias)=3134, cap was 256-1) Add a small alias_append() helper around vsnprintf with a remaining- space check and call fatal() on overflow, matching the modpost style for unrecoverable build conditions. do_input() takes the buffer size as a new parameter; do_input_entry() and do_dmi_entry() pass sizeof(alias) at every call site. dmi_ascii_filter() takes the remaining buffer size as well and aborts on truncation. This bounds every write into the on-stack buffers and turns the latent overflow into a clean build error if it is ever reached. Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support") Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com> Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com Signed-off-by: Nicolas Schier <nsc@kernel.org>