summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-11-07perf/x86/intel: Initialize architectural PEBSDapeng Mi
arch-PEBS leverages CPUID.23H.4/5 sub-leaves enumerate arch-PEBS supported capabilities and counters bitmap. This patch parses these 2 sub-leaves and initializes arch-PEBS capabilities and corresponding structures. Since IA32_PEBS_ENABLE and MSR_PEBS_DATA_CFG MSRs are no longer existed for arch-PEBS, arch-PEBS doesn't need to manipulate these MSRs. Thus add a simple pair of __intel_pmu_pebs_enable/disable() callbacks for arch-PEBS. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251029102136.61364-6-dapeng1.mi@linux.intel.com
2025-11-07perf/x86/intel: Correct large PEBS flag checkDapeng Mi
current large PEBS flag check only checks if sample_regs_user contains unsupported GPRs but doesn't check if sample_regs_intr contains unsupported GPRs. Of course, currently PEBS HW supports to sample all perf supported GPRs, the missed check doesn't cause real issue. But it won't be true any more after the subsequent patches support to sample SSP register. SSP sampling is not supported by adaptive PEBS HW and it would be supported until arch-PEBS HW. So correct this issue. Fixes: a47ba4d77e12 ("perf/x86: Enable free running PEBS for REGS_USER/INTR") Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251029102136.61364-5-dapeng1.mi@linux.intel.com
2025-11-07perf/x86/intel: Replace x86_pmu.drain_pebs calling with static callDapeng Mi
Use x86_pmu_drain_pebs static call to replace calling x86_pmu.drain_pebs function pointer. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251029102136.61364-4-dapeng1.mi@linux.intel.com
2025-11-07perf/x86: Fix NULL event access and potential PEBS record lossDapeng Mi
When intel_pmu_drain_pebs_icl() is called to drain PEBS records, the perf_event_overflow() could be called to process the last PEBS record. While perf_event_overflow() could trigger the interrupt throttle and stop all events of the group, like what the below call-chain shows. perf_event_overflow() -> __perf_event_overflow() ->__perf_event_account_interrupt() -> perf_event_throttle_group() -> perf_event_throttle() -> event->pmu->stop() -> x86_pmu_stop() The side effect of stopping the events is that all corresponding event pointers in cpuc->events[] array are cleared to NULL. Assume there are two PEBS events (event a and event b) in a group. When intel_pmu_drain_pebs_icl() calls perf_event_overflow() to process the last PEBS record of PEBS event a, interrupt throttle is triggered and all pointers of event a and event b are cleared to NULL. Then intel_pmu_drain_pebs_icl() tries to process the last PEBS record of event b and encounters NULL pointer access. To avoid this issue, move cpuc->events[] clearing from x86_pmu_stop() to x86_pmu_del(). It's safe since cpuc->active_mask or cpuc->pebs_enabled is always checked before access the event pointer from cpuc->events[]. Closes: https://lore.kernel.org/oe-lkp/202507042103.a15d2923-lkp@intel.com Fixes: 9734e25fbf5a ("perf: Fix the throttle logic for a group") Reported-by: kernel test robot <oliver.sang@intel.com> Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251029102136.61364-3-dapeng1.mi@linux.intel.com
2025-11-07perf/x86: Remove redundant is_x86_event() prototypeDapeng Mi
2 is_x86_event() prototypes are defined in perf_event.h. Remove the redundant one. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20251029102136.61364-2-dapeng1.mi@linux.intel.com
2025-11-07regmap: sdw-mbq: Reorder regmap_mbq_context struct for better packingCharles Keepax
Avoid a hole in struct regmap_mbq_context by shuffling the members slightly. Pahole before: struct regmap_mbq_context { struct device * dev; /* 0 8 */ struct sdw_slave * sdw; /* 8 8 */ struct regmap_sdw_mbq_cfg cfg; /* 16 32 */ int val_size; /* 48 4 */ /* XXX 4 bytes hole, try to pack */ bool (*readable_reg)(struct device *, unsigned int); /* 56 8 */ /* size: 64, cachelines: 1, members: 5 */ /* sum members: 60, holes: 1, sum holes: 4 */ }; Pahole after: struct regmap_mbq_context { struct device * dev; /* 0 8 */ struct sdw_slave * sdw; /* 8 8 */ bool (*readable_reg)(struct device *, unsigned int); /* 16 8 */ struct regmap_sdw_mbq_cfg cfg; /* 24 32 */ int val_size; /* 56 4 */ /* size: 64, cachelines: 1, members: 5 */ /* padding: 4 */ }; Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20251107104551.1553526-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-07arch_topology: Provide a stub topology_core_has_smt() for ↵Yicong Yang
!CONFIG_GENERIC_ARCH_TOPOLOGY The arm_pmu driver is using topology_core_has_smt() for retrieving the SMT implementation which depends on CONFIG_GENERIC_ARCH_TOPOLOGY. The config is optional on arm platforms so provide a !CONFIG_GENERIC_ARCH_TOPOLOGY stub for topology_core_has_smt(). Fixes: c3d78c34ad00 ("perf: arm_pmuv3: Don't use PMCCNTR_EL0 on SMT cores") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511041757.vuCGOmFc-lkp@intel.com/ Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Yicong Yang <yangyccccc@gmail.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-07perf/arm-ni: Fix and optimise register offset calculationRobin Murphy
LKP points out an operator precedence oversight in the new NoC S3 support that, annoyingly, my local W=1 build didn't flag. In fixing that, we can also take the similarly-missed opportunity to cache the version check itself at event_init time. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511041749.ok8zDP6u-lkp@intel.com/ Fixes: 8fa08f8835e5 ("perf/arm-ni: Add NoC S3 support") Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2025-11-07refscale: Do not disable interrupts for tests involving local_bh_enable()Paul E. McKenney
Some kernel configurations prohibit invoking local_bh_enable() while interrupts are disabled. However, refscale disables interrupts to reduce OS noise during the tests, which results in splats. This commit therefore adds an ->enable_irqs flag to the ref_scale_ops structure, and refrains from disabling interrupts when that flag is set. This flag is set for the "bh" and "incpercpubh" scale_type module-parameter values. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07refscale: Add non-atomic per-CPU increment readersPaul E. McKenney
This commit adds refscale readers based on READ_ONCE() and WRITE_ONCE() that are unprotected (can lose counts, "refscale.scale_type=incpercpu"), preempt-disabled ("refscale.scale_type=incpercpupreempt"), bh-disabled ("refscale.scale_type=incpercpubh"), and irq-disabled ("refscale.scale_type=incpercpuirqsave"). On my x86 laptop, these are about 4.3ns, 3.8ns, and 7.3ns per pair, respectively. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07refscale: Add this_cpu_inc() readersPaul E. McKenney
This commit adds refscale readers based on this_cpu_inc() and this_cpu_inc() ("refscale.scale_type=percpuinc"). On my x86 laptop, these are about 4.5ns per pair. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07refscale: Add preempt_disable() readersPaul E. McKenney
This commit adds refscale readers based on preempt_disable() and preempt_enable() ("refscale.scale_type=preempt"). On my x86 laptop, these are about 2.8ns. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07refscale: Add local_bh_disable() readersPaul E. McKenney
This commit adds refscale readers based on local_bh_disable() and local_bh_enable() ("refscale.scale_type=bh"). On my x86 laptop, these are about 4.9ns. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07refscale: Add local_irq_disable() and local_irq_save() readersPaul E. McKenney
This commit adds refscale readers based on local_irq_disable() and local_irq_enable() ("refscale.scale_type=irq") and on local_irq_save() and local_irq_restore ("refscale.scale_type=irqsave"). On my x86 laptop, these are about 2.8ns and 7.5ns per enable/disable pair, respectively. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07drm/i915/psr: fix pipe to vblank conversionJani Nikula
First, we can't assume pipe == crtc index. If a pipe is fused off in between, it no longer holds. intel_crtc_for_pipe() is the only proper way to get from a pipe to the corresponding crtc. Second, drivers aren't supposed to access or index drm->vblank[] directly. There's drm_crtc_vblank_crtc() for this. Use both functions to fix the pipe to vblank conversion. Fixes: f02658c46cf7 ("drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable") Cc: Jouni Högander <jouni.hogander@intel.com> Cc: stable@vger.kernel.org # v6.16+ Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20251106200000.1455164-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07coresight: tpdm: remove redundant check for drvdataJie Gan
Remove the redundant check for drvdata data because the drvdata here already has been guarranted to be non-NULL. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20251107-fix_tpdm_redundant_check-v1-1-b63468a2dd73@oss.qualcomm.com
2025-11-07printk: nbcon: Allow unsafe write_atomic() for panicJohn Ogness
There may be console drivers that have not yet figured out a way to implement safe atomic printing (->write_atomic() callback). These drivers could choose to only implement threaded printing (->write_thread() callback), but then it is guaranteed that _no_ output will be printed during panic. Not even attempted. As a result, developers may be tempted to implement unsafe ->write_atomic() callbacks and/or implement some sort of custom deferred printing trickery to try to make it work. This goes against the principle intention of the nbcon API as well as endangers other nbcon drivers that are doing things correctly (safely). As a compromise, allow nbcon drivers to implement unsafe ->write_atomic() callbacks by providing a new console flag CON_NBCON_ATOMIC_UNSAFE. When specified, the ->write_atomic() callback for that console will _only_ be called during the final "hope and pray" flush attempt at the end of a panic: nbcon_atomic_flush_unsafe(). Signed-off-by: John Ogness <john.ogness@linutronix.de> Link: https://lore.kernel.org/lkml/b2qps3uywhmjaym4mht2wpxul4yqtuuayeoq4iv4k3zf5wdgh3@tocu6c7mj4lt Reviewed-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/all/swdpckuwwlv3uiessmtnf2jwlx3jusw6u7fpk5iggqo4t2vdws@7rpjso4gr7qp/ [1] Link: https://lore.kernel.org/all/20251103-fix_netpoll_aa-v4-1-4cfecdf6da7c@debian.org/ [2] Link: https://patch.msgid.link/20251027161212.334219-2-john.ogness@linutronix.de [pmladek@suse.com: Fix build with rework/nbcon-in-kdb branch.] Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-11-07tracing/tools: Fix incorrcet short option in usage text for --threadsZhang Chujun
The help message incorrectly listed '-t' as the short option for --threads, but the actual getopt_long configuration uses '-e'. This mismatch can confuse users and lead to incorrect command-line usage. This patch updates the usage string to correctly show: "-e, --threads NRTHR" to match the implementation. Note: checkpatch.pl reports a false-positive spelling warning on 'Run', which is intentional. Link: https://patch.msgid.link/20251106031040.1869-1-zhangchujun@cmss.chinamobile.com Signed-off-by: Zhang Chujun <zhangchujun@cmss.chinamobile.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-11-07torture: Permit negative kvm.sh --kconfig numberic argumentsPaul E. McKenney
This commit loosens the kvm.sh script's regular expressions to permit negative-valued Kconfig options, for example: --kconfig CONFIG_CMDLINE_LOG_WRAP_IDEAL_LEN=-1 Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07srcu: Add SRCU_READ_FLAVOR_FAST_UPDOWN CPP macroPaul E. McKenney
This commit adds the SRCU_READ_FLAVOR_FAST_UPDOWN=0x8 macro and adjusts rcutorture to make use of it. In this commit, both SRCU_READ_FLAVOR_FAST=0x4 and the new SRCU_READ_FLAVOR_FAST_UPDOWN test SRCU-fast. When the SRCU-fast-updown is added, the new SRCU_READ_FLAVOR_FAST_UPDOWN macro will test it when passed to the rcutorture.reader_flavor module parameter. The old SRCU_READ_FLAVOR_FAST macro's value changed from 0x8 to 0x4. Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: <bpf@vger.kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07rcu: Mark diagnostic functions as notracePaul E. McKenney
The rcu_lockdep_current_cpu_online(), rcu_read_lock_sched_held(), rcu_read_lock_held(), rcu_read_lock_bh_held(), rcu_read_lock_any_held() are used by tracing-related code paths, so putting traces on them is unlikely to make anyone happy. This commit therefore marks them all "notrace". Reported-by: Leon Hwang <leon.hwang@linux.dev> Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
2025-11-07RAS/CEC: Replace use of system_wq with system_percpu_wqMarco Crivellari
Switch to using system_percpu_wq because system_wq is going away as part of a workqueue restructuring. Currently if a user enqueues a work item using schedule_delayed_work() the used workqueue is "system_wq" (per-cpu workqueue) while queue_delayed_work() uses WORK_CPU_UNBOUND (used when a CPU is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use of WORK_CPU_UNBOUND again. This lack of consistency cannot be addressed without refactoring the API. For more details see those commits and the Link tag below. 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") [ bp: Massage commit message. ] Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de
2025-11-07drm/xe: Enforce correct user fence signaling order usingMatthew Brost
Prevent application hangs caused by out-of-order fence signaling when user fences are attached. Use drm_syncobj (via dma-fence-chain) to guarantee that each user fence signals in order, regardless of the signaling order of the attached fences. Ensure user fence writebacks to user space occur in the correct sequence. v7: - Skip drm_syncbj create of error (CI) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20251031234050.3043507-2-matthew.brost@intel.com (cherry picked from commit adda4e855ab6409a3edaa585293f1f2069ab7299) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07block: don't return 1 for the fallback case in blkdev_get_zone_infoChristoph Hellwig
blkdev_do_report_zones returns the number of reported zones, but blkdev_get_zone_info returns 0 or an errno. Translate to the expected return value in blkdev_report_zone_fallback. Fixes: b037d41762fd ("block: introduce blkdev_get_zone_info()") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-11-07x86/microcode/AMD: Add more known models to entry sign checkingMario Limonciello (AMD)
Two Zen5 systems are missing from need_sha_check(). Add them. Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20251106182904.4143757-1-superm1@kernel.org
2025-11-07drm/xe: Do clean shutdown also when using flrJouni Högander
Currently Xe driver is triggering flr without any clean-up on shutdown. This is causing random warnings from pending related works as the underlying hardware is reset in the middle of their execution. Fix this by performing clean shutdown also when using flr. Fixes: 501d799a47e2 ("drm/xe: Wire up device shutdown handler") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Maarten Lankhorst <dev@lankhorst.se> Link: https://patch.msgid.link/20251031122312.1836534-1-jouni.hogander@intel.com Signed-off-by: Maarten Lankhorst <dev@lankhorst.se> (cherry picked from commit a4ff26b7c8ef38e4dd34f77cbcd73576fdde6dd4) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe: Move declarations under conditional branchTejas Upadhyay
The xe_device_shutdown() function was needing a few declarations that were only required under a specific condition. This change moves those declarations to be within that conditional branch to avoid unnecessary declarations. Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20251007100208.1407021-1-tejas.upadhyay@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit 15b3036045188f4da4ca62b2ed01b0f160252e9b) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07drm/xe/guc: Synchronize Dead CT worker with unbindBalasubramani Vivekanandan
Cancel and wait for any Dead CT worker to complete before continuing with device unbinding. Else the worker will end up using resources freed by the undind operation. Cc: Zhanjun Dong <zhanjun.dong@intel.com> Fixes: d2c5a5a926f4 ("drm/xe/guc: Dead CT helper") Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patch.msgid.link/20251103123144.3231829-6-balasubramani.vivekanandan@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 492671339114e376aaa38626d637a2751cdef263) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-11-07iommupt: Documentation fixesJason Gunthorpe
Some adjustments pointed out by Randy: "decodes an full 64-bit" -> "decodes the full 64 bit" Correct the function parameter name for iova_to_phys() Use the recommended section heading style. Suggested-by: Randy Dunlap <rdunlap@infradead.org> Fixes: ab0b572847ac ("genpt: Add Documentation/ files") Fixes: 879ced2bab1b ("iommupt: Add the AMD IOMMU v1 page table format") Fixes: 9d4c274cd7d5 ("iommupt: Add iova_to_phys op") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-07iommupt: Describe @bitnr parameterBagas Sanjaya
Sphinx reports kernel-doc warnings when making htmldocs: WARNING: ./drivers/iommu/generic_pt/pt_common.h:361 function parameter 'bitnr' not described in 'pt_test_sw_bit_acquire' WARNING: ./drivers/iommu/generic_pt/pt_common.h:371 function parameter 'bitnr' not described in 'pt_set_sw_bit_release' Describe @bitnr to squash them. Fixes: bcc64b57b48e ("iommupt: Add basic support for SW bits in the page table") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-07Documentation: genpt: Don't use code block marker before iommu_amdv1.c ↵Bagas Sanjaya
include listing Stephen Rothwell reports htmldocs warning when merging iommu tree: Documentation/driver-api/generic_pt.rst:32: WARNING: Literal block expected; none found. [docutils] This is because of duplicate double colon code block markers: one after generic_pt/fmt/iommu_amdv1.c and the one in its preceding paragraph. The resulting htmldocs, however, only marks the include listing (after the former) up as it should be. Drop the latter to fix the warning. Fixes: ab0b572847ac ("genpt: Add Documentation/ files") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/linux-next/20251106143925.578e411b@canb.auug.org.au/ Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-07thunderbolt: Replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") Replace system_wq with system_percpu_wq, keeping the old behavior. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2025-11-07regulator: mt6363: Remove unneeded semicolonChen Ni
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the semantic patch at scripts/coccinelle/misc/semicolon.cocci. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20251107085109.2316999-1-nichen@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-07regulator: irq_helper: replace use of system_wq with system_dfl_wqMarco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This specific workload do not benefit from a per-cpu workqueue, so use the default unbound workqueue (system_dfl_wq) instead. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20251106142914.227875-1-marco.crivellari@suse.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-07spi: xilinx: increase number of retries before declaring stallAlvaro Gamez Machado
SPI devices using a (relative) slow frequency need a larger time. For instance, microblaze running at 83.25MHz and performing a 3 bytes transaction using a 10MHz/16 = 625kHz needed this stall value increased to at least 20. The SPI device is quite slow, but also is the microblaze, so set this value to 32 to give it even more margin. Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> Link: https://patch.msgid.link/20251106134545.31942-1-alvaro.gamez@hazent.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-07ASoC: tas2781: fix getting the wrong device numberShenghao Ding
The return value of device_property_read_u32_array used for getting the property is the status instead of the number of the property. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding <shenghao-ding@ti.com> Link: https://patch.msgid.link/20251107054959.950-1-shenghao-ding@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-11-07spi: enable the SpacemiT K1 SoC QSPIMark Brown
Merge series from Alex Elder <elder@riscstar.com>: This series adds support for the SpacemiT K1 SoC QSPI. This IP is generally compatible with the Freescale QSPI driver, requiring three minor changes to enable it to be supported. The changes are: - Adding support for optional resets - Having the clock *not* be disabled when changing its rate - Allowing the size of storage blocks written to flash chips to be set to something different from the AHB buffer size
2025-11-07rust: pwm: Drop wrapping of PWM polarity and stateUwe Kleine-König
These were introduced and used in an earlier revision of the patch that became commit fb3957af9ec6 ("pwm: Add Rust driver for T-HEAD TH1520 SoC"). The variant that was actually applied sticks to the modern waveform abstraction only (and other drivers are supposed to do that, too), so they can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/20251025122359.361372-2-u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-07rust: pwm: Add module_pwm_platform_driver! macroMichal Wilczynski
Rust PWM drivers using the abstractions in `kernel/pwm.rs` typically call C functions (like `pwmchip_alloc`, `__pwmchip_add`, etc.) that are exported to the `PWM` C symbol namespace. With the introduction of `imports_ns` support in the `module!` macro, every PWM driver would need to manually include `imports_ns: ["PWM"]` in its module declaration. To simplify this for driver authors and ensure consistency, introduce a new helper macro `module_pwm_platform_driver!` in `pwm.rs`. This macro wraps the standard `module_platform_driver!`, forwards all user provided arguments using the `($($user_args:tt)*)` pattern, and automatically injects the `imports_ns: ["PWM"]` declaration. This follows the pattern used in other subsystems (e.g., `module_pci_driver!`) to provide specialized module registration helpers. It makes writing PWM drivers slightly simpler and less error prone regarding namespace imports. Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Link: https://patch.msgid.link/20251028-pwm_fixes-v1-2-25a532d31998@samsung.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-07rust: pwm: Add complete abstraction layerMichal Wilczynski
Introduce a comprehensive abstraction layer for the PWM subsystem to enable writing drivers in Rust. Because `Device`, `Chip`, and `PwmOps` all refer to each other, they form a single, indivisible unit with circular dependencies. They are introduced together in this single commit to create a complete, compilable abstraction layer. The main components are: - Data Wrappers: Safe, idiomatic wrappers for core C types like `pwm_device`, and `pwm_chip`. - PwmOps Trait: An interface that drivers can implement to provide their hardware-specific logic, mirroring the C `pwm_ops` interface. - FFI VTable and Adapter: A bridge to connect the high-level PwmOps trait to the C kernel's pwm_ops vtable. - Allocation and Lifetime Management: A high-level `Chip::new()` API to safely allocate a chip and a `Registration` guard that integrates with `devres` to manage the chip's registration with the PWM core. An `AlwaysRefCounted` implementation and a custom release handler prevent memory leaks by managing the chip's lifetime and freeing driver data correctly. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-3-a5df2405d2bd@samsung.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-07rust: pwm: Add Kconfig and basic data structuresMichal Wilczynski
Introduce the foundational support for PWM abstractions in Rust. This commit adds the `RUST_PWM_ABSTRACTIONS` Kconfig option to enable the feature, along with the necessary build-system support and C helpers. It also introduces the first set of safe wrappers for the PWM subsystem, covering the basic data carrying C structs and enums: - `Polarity`: A safe wrapper for `enum pwm_polarity`. - `Waveform`: A wrapper for `struct pwm_waveform`. - `State`: A wrapper for `struct pwm_state`. These types provide memory safe, idiomatic Rust representations of the core PWM data structures and form the building blocks for the abstractions that will follow. Tested-by: Drew Fustini <fustini@kernel.org> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-2-a5df2405d2bd@samsung.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-07pwm: Export `pwmchip_release` for external useMichal Wilczynski
The upcoming Rust abstraction layer for the PWM subsystem uses a custom `dev->release` handler to safely manage the lifetime of its driver data. To prevent leaking the memory of the `struct pwm_chip` (allocated by `pwmchip_alloc`), this custom handler must also call the original `pwmchip_release` function to complete the cleanup. Make `pwmchip_release` a global, exported function so that it can be called from the Rust FFI bridge. This involves removing the `static` keyword, adding a prototype to the public header, and exporting the symbol. Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://patch.msgid.link/20251016-rust-next-pwm-working-fan-for-sending-v16-1-a5df2405d2bd@samsung.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-07rust: macros: Add support for 'imports_ns' to module!Michal Wilczynski
Kernel modules that use C symbols exported via `EXPORT_SYMBOL_NS` must declare this dependency for `modpost` verification. C modules achieve this by using the `MODULE_IMPORT_NS(NAMESPACE)` macro, which embeds an `import_ns=<NAMESPACE>` tag into the `.modinfo` section. The Rust `module!` macro lacked the ability to generate these tags, resulting in build warnings for Rust drivers (like the PWM driver) that call namespaced C functions. Modify the `module!` macro's internal parser (`ModuleInfo`) to accept a new optional field `imports_ns`, which takes an array of namespace strings. Update the code generator (`ModInfoBuilder::emit`) loop to iterate over these strings and emit the corresponding `import_ns=<NAMESPACE>` tags into the `.modinfo` section using the existing `#[link_section]` mechanism. This provides the necessary infrastructure for Rust modules to correctly declare their C namespace dependencies. Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev> Acked-by: Daniel Gomez <da.gomez@samsung.com> Link: https://patch.msgid.link/20251028-pwm_fixes-v1-1-25a532d31998@samsung.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-11-07slab: prevent recursive kmalloc() in alloc_empty_sheaf()Vlastimil Babka
We want to expand usage of sheaves to all non-boot caches, including kmalloc caches. Since sheaves themselves are also allocated by kmalloc(), we need to prevent excessive or infinite recursion - depending on sheaf size, the sheaf can be allocated from smaller, same or larger kmalloc size bucket, there's no particular constraint. This is similar to allocating the objext arrays so let's just reuse the existing mechanisms for those. __GFP_NO_OBJ_EXT in alloc_empty_sheaf() will prevent a nested kmalloc() from allocating a sheaf itself - it will either have sheaves already, or fallback to a non-sheaf-cached allocation (so bootstrap of sheaves in a kmalloc cache that allocates sheaves from its own size bucket is possible). Additionally, reuse OBJCGS_CLEAR_MASK to clear unwanted gfp flags from the nested allocation. Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-5-b8218e1ac7ef@suse.cz Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-11-07slab: make __slab_free() more clearVlastimil Babka
The function is tricky and many of its tests are hard to understand. Try to improve that by using more descriptively named variables and added comments. - rename 'prior' to 'old_head' to match the head and tail parameters - introduce a 'bool was_full' to make it more obvious what we are testing instead of the !prior and prior tests - add or improve comments in various places to explain what we're doing Also replace kmem_cache_has_cpu_partial() tests with IS_ENABLED(CONFIG_SLUB_CPU_PARTIAL) which are compile-time constants. We can do that because the kmem_cache_debug(s) case is handled upfront via free_to_partial_list(). Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-1-b8218e1ac7ef@suse.cz Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-11-07slub: remove CONFIG_SLUB_TINY specific code pathsVlastimil Babka
CONFIG_SLUB_TINY minimizes the SLUB's memory overhead in multiple ways, mainly by avoiding percpu caching of slabs and objects. It also reduces code size by replacing some code paths with simplified ones through ifdefs, but the benefits of that are smaller and would complicate the upcoming changes. Thus remove these code paths and associated ifdefs and simplify the code base. Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-4-b8218e1ac7ef@suse.cz Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-11-07slab: handle pfmemalloc slabs properly with sheavesVlastimil Babka
When a pfmemalloc allocation actually dips into reserves, the slab is marked accordingly and non-pfmemalloc allocations should not be allowed to allocate from it. The sheaves percpu caching currently doesn't follow this rule, so implement it before we expand sheaves usage to all caches. Make sure objects from pfmemalloc slabs don't end up in percpu sheaves. When freeing, skip sheaves when freeing an object from pfmemalloc slab. When refilling sheaves, use __GFP_NOMEMALLOC to override any pfmemalloc context - the allocation will fallback to regular slab allocations when sheaves are depleted and can't be refilled because of the override. For kfree_rcu(), detect pfmemalloc slabs after processing the rcu_sheaf after the grace period in __rcu_free_sheaf_prepare() and simply flush it if any object is from pfmemalloc slabs. For prefilled sheaves, try to refill them first with __GFP_NOMEMALLOC and if it fails, retry without __GFP_NOMEMALLOC but then mark the sheaf pfmemalloc, which makes it flushed back to slabs when returned. Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-3-b8218e1ac7ef@suse.cz Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-11-07slab: move kfence_alloc() out of internal bulk allocVlastimil Babka
SLUB's internal bulk allocation __kmem_cache_alloc_bulk() can currently allocate some objects from KFENCE, i.e. when refilling a sheaf. It works but it's conceptually the wrong layer, as KFENCE allocations should only happen when objects are actually handed out from slab to its users. Currently for sheaf-enabled caches, slab_alloc_node() can return KFENCE object via kfence_alloc(), but also via alloc_from_pcs() when a sheaf was refilled with KFENCE objects. Continuing like this would also complicate the upcoming sheaf refill changes. Thus remove KFENCE allocation from __kmem_cache_alloc_bulk() and move it to the places that return slab objects to users. slab_alloc_node() is already covered (see above). Add kfence_alloc() to kmem_cache_alloc_from_sheaf() to handle KFENCE allocations from prefilled sheafs, with a comment that the caller should not expect the sheaf size to decrease after every allocation because of this possibility. For kmem_cache_alloc_bulk() implement a different strategy to handle KFENCE upfront and rely on internal batched operations afterwards. Assume there will be at most once KFENCE allocation per bulk allocation and then assign its index in the array of objects randomly. Cc: Alexander Potapenko <glider@google.com> Cc: Marco Elver <elver@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Link: https://patch.msgid.link/20251105-sheaves-cleanups-v1-2-b8218e1ac7ef@suse.cz Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-11-07drm/vmwgfx: Set surface-framebuffer GEM objectsThomas Zimmermann
Set struct drm_framebuffer.obj[0] to the allocated GEM buffer object for surface framebuffers. Avoids a NULL-pointer deref in the client's vmap helpers. [ 22.640191] Console: switching to colour frame buffer device 160x50 [ 22.641788] Oops: general protection fault, probably for non-canonical address 0xdffffc000000001f: 0000 [#1] SMP KASAN NOPTI [ 22.641795] KASAN: null-ptr-deref in range [0x00000000000000f8-0x00000000000000ff] [...] [ 22.641809] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.24928539.B64.2508260915 08/26/2025 [ 22.641812] Workqueue: events drm_fb_helper_damage_work [ 22.641824] RIP: 0010:drm_gem_lock+0x25/0x50 [ 22.641831] Code: 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 53 48 89 fb 48 81 c7 f8 00 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 0f 48 8b bb f8 00 00 00 31 f6 5b e9 16 2e 15 01 e8 [...] [ 22.641889] Call Trace: [ 22.641891] <TASK> [ 22.641894] drm_client_buffer_vmap_local+0x78/0x140 [ 22.641903] drm_fbdev_ttm_helper_fb_dirty+0x20c/0x510 [drm_ttm_helper] [ 22.641913] ? __pfx_drm_fbdev_ttm_helper_fb_dirty+0x10/0x10 [drm_ttm_helper] [ 22.641918] ? __raw_spin_lock_irqsave+0x8c/0xf0 [ 22.641924] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 [ 22.641928] ? __pfx_mutex_lock+0x10/0x10 [ 22.641936] drm_fb_helper_fb_dirty+0x29a/0x5e0 [ 22.641942] ? __pfx_drm_fb_helper_fb_dirty+0x10/0x10 [...] Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: ea39f2e66e61 ("drm/client: Deprecate struct drm_client_buffer.gem") Reported-by: Ian Forbes <ian.forbes@broadcom.com> Closes: https://lore.kernel.org/dri-devel/CAO6MGtjg8PiRiSLomJQRBduTBSC0WkqX67tEZwA9qwOgRzchpw@mail.gmail.com/ Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Tested-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20251104103611.167821-1-tzimmermann@suse.de
2025-11-07drm/vblank: Increase timeout in drm_wait_one_vblank()Chintan Patel
Currently, wait_event_timeout() in drm_wait_one_vblank() uses a 100ms timeout. Under heavy scheduling pressure or rare delayed vblank handling, this can trigger WARNs unnecessarily. Increase the timeout to 1000ms to reduce spurious WARNs, while still catching genuine issues. Reported-by: syzbot+147ba789658184f0ce04@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=147ba789658184f0ce04 Tested-by: syzbot+147ba789658184f0ce04@syzkaller.appspotmail.com Signed-off-by: Chintan Patel <chintanlike@gmail.com> v2: - Dropped unnecessary in-code comment (suggested by Thomas Zimmermann) - Removed else branch, only log timeout case v3: - Replaced drm_dbg_kms()/manual logging with drm_err() (suggested by Ville Syrjälä) - Removed unnecessary curr = drm_vblank_count() (suggested by Thomas Zimmermann) - Fixed commit message wording ("invalid userspace calls" → "delayed vblank handling") v4: - Keep the original drm_WARN() to catch genuine kernel issues - Increased timeout from 100ms → 1000ms to reduce spurious WARNs (suggested by Thomas Zimmermann) Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251028034337.6341-1-chintanlike@gmail.com