summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-11-07drm/i915/gem: ↵Ville Syrjälä
s/i915_gem_object_get_frontbuffer/i915_gem_object_frontbuffer_lookup/ The i915_gem_object_get_frontbuffer() name is rather confusing wrt. intel_frontbuffer_get(). Rename to i915_gem_object_frontbuffer_lookup() to make things less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Fix intel_frontbuffer lifetime handlingVille Syrjälä
The current attempted split between xe/i915 vs. display for intel_frontbuffer is a mess: - the i915 rcu leaks through the interface to the display side - the obj->frontbuffer write-side is now protected by a display specific spinlock even though the actual obj->framebuffer pointer lives in a i915 specific structure - the kref is getting poked directly from both sides - i915_active is still on the display side Clean up the mess by moving everything about the frontbuffer lifetime management to the i915/xe side: - the rcu usage is now completely contained in i915 - frontbuffer_lock is moved into i915 - kref is on the i915/xe side (xe needs the refcount as well due to intel_frontbuffer_queue_flush()->intel_frontbuffer_ref()) - the bo (and its refcounting) is no longer on the display side - i915_active is contained in i915 I was pondering whether we could do this in some kind of smaller steps, and perhaps we could, but it would probably have to start with a bunch of reverts (which for sure won't go cleanly anymore). So not convinced it's worth the hassle. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-10-ville.syrjala@linux.intel.com
2025-11-07drm/i915/frontbuffer: Add intel_frontbuffer::displayVille Syrjälä
After upcoming intel_frontbuffer lifetime related changes we won't need intel_frontbuffer::obj for anything apart from getting at the display. Add a direct pointer for that instead so that the obj pointer can be completely eliminated. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Extract intel_frontbuffer_ref()Ville Syrjälä
I want to hide the kref from the high level frontbuffer code. To that end abstract the kref_get() in intel_frontbuffer_queue_flush() (which is the only high level function that needs this) as a new intel_frontbuffer_ref(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Split fb_tracking.lock into twoVille Syrjälä
Our fb_tracking.lock is serving a double duty: - protects fb_tracking.busy_bits - provides the write-side protection for obj->frontbuffer Split obj->frontbuffer role into a separate lock so that we can clean up the current mess with the frontbuffer lifetime management. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Handle the dirtyfb cache flush inside ↵Ville Syrjälä
intel_frontbuffer_flush() intel_bo_frontbuffer_flush_for_display() is a bit too low level to be directly in the high level dirtyfb code. Move the calls into intel_frontbuffer_flush(). There is a slight behavioural change here in that we now skip the flush if the bo is not a current scanout buffer (front->bits == 0). But that is fine as the flush will eventually happen via the fb pinning code if/when the bo becomes a scanout buffer again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Turn intel_bo_flush_if_display() into a frontbuffer ↵Ville Syrjälä
operation Convert intel_bo_flush_if_display() to be an operation on the frontbuffer object rather than the underlying gem bo. This will help with cleaning up the frontbuffer xe/i915 vs. display split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/frontbuffer: Nuke intel_frontbuffer_flip_{prepare,complete}()Ville Syrjälä
Get rid of intel_frontbuffer_flip_{prepare,complete}() (and the accompanying flip_bits) since they are unused. I suppose these could technically provide a minor optimization over intel_frontbuffer_flip() in that the flush would get deferred further if new rendering were to sneak in between the prepare() and complete() calls. But for correctness it should not make any difference since another flush will anyway follow once the new rendering finishes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2025-11-07drm/i915/overlay: Switch to intel_frontbuffer_flip()Ville Syrjälä
Get rid of intel_frontbuffer_flip_{prepare,complete}() from the overlay code and just use intel_frontbuffer_flip() instead. The only difference between these are the light interactions with the ORIGIN_CS busyness tracking, but since the only user of this is the overlay/xf86-video-intel/Xv the buffer will always be filled by the CPU and thus we'll never see any ORIGIN_CS frontbuffer activity there anyway. Also I don't think we actually have anything covered by the frontbuffer tracking that affects the overlay (FBC is on the primary plane, DRRS isn't currently enabled on the platforms with overlay, and PSR doesn't exist in the hardware). Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-3-ville.syrjala@linux.intel.com
2025-11-07drm/i915/overlay: Drop the DIRTYFB flushVille Syrjälä
I don't even know why we have this DIRTYFB flush in the overlay code. We'll anyway call intel_frontbuffer_flip() so there should be no need to pretend that this is some kind of frontbuffer only rendering operation. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20251016185408.22735-2-ville.syrjala@linux.intel.com
2025-11-07iommu/iommupt: Fix build error in genericpt unit-testsJoerg Roedel
Fix the include of iommu-pages.h in the KUnit tests for the IOMMU generic page-table code to make the tests compile again. Reported-by: Thorsten Leemhuis <linux@leemhuis.info> Closes: https://lore.kernel.org/all/9844d4cb-f517-478b-9911-b6dc1a963b8e@leemhuis.info/ Reported-by: "Longia, Amandeep Kaur" <amandeepkaur.longia@amd.com> Closes: https://lore.kernel.org/all/e641c955-25ad-4eae-b3fe-4392966cf768@amd.com/ Fixes: 1dd4187f53c3 ("iommupt: Add a kunit test for Generic Page Table") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-11-07gpu: nova-core: Simplify `DmaObject::from_data` in nova-core/dma.rsDaniel del Castillo
This patch solves one of the existing mentions of COHA, a task in the Nova task list about improving the `CoherentAllocation` API. It uses the `write` method from `CoherentAllocation`. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-3-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: Fix capitalization of some commentsDaniel del Castillo
Some comments that already existed didn't start with a capital letter, this patch fixes that. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-2-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: Simplify `transmute` and `transmute_mut` in fwsec.rsDaniel del Castillo
This patch solves one of the existing mentions of COHA, a task in the Nova task list about improving the `CoherentAllocation` API. It uses the new `from_bytes` method from the `FromBytes` trait as well as the `as_slice` and `as_slice_mut` methods from `CoherentAllocation`. Signed-off-by: Daniel del Castillo <delcastillodelarosadaniel@gmail.com> [acourbot@nvidia.com: set prefix to "gpu: nova-core:".] [acourbot@nvidia.com: fix merge conflict after imports refactor.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251104193756.57726-1-delcastillodelarosadaniel@gmail.com>
2025-11-07gpu: nova-core: apply the one "use" item per line policyJohn Hubbard
As per [1], we need one "use" item per line, in order to reduce merge conflicts. Furthermore, we need a trailing ", //" in order to tell rustfmt(1) to leave it alone. This does that for the entire nova-core driver. [1] https://docs.kernel.org/rust/coding-guidelines.html#imports Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: John Hubbard <jhubbard@nvidia.com> [acourbot@nvidia.com: remove imports already in prelude as pointed out by Danilo.] [acourbot@nvidia.com: remove a few unneeded trailing `//`.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Message-ID: <20251107021006.434109-1-jhubbard@nvidia.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-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-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-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-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-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-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: 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-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
2025-11-07drm/vblank: Fix kernel docs for vblank timerThomas Zimmermann
Fix documentation for drm_crtc_vblank_start_timer(), which referred to drm_crtc_vblank_cancel_timer(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20251106152201.6f248c09@canb.auug.org.au/ Fixes: 74afeb812850 ("drm/vblank: Add vblank timer") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Louis Chauvet <louis.chauvet@bootlin.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: Simona Vetter <simona@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com> Link: https://patch.msgid.link/20251106073207.11192-1-tzimmermann@suse.de
2025-11-07ata: libata-sff: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
Currently if a user enqueue 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. alloc_workqueue() treats all queues as per-CPU by default, while unbound workqueues must opt-in via WQ_UNBOUND. This default is suboptimal: most workloads benefit from unbound queues, allowing the scheduler to place worker threads where they’re needed and reducing noise when CPUs are isolated. This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") This change adds a new WQ_PERCPU flag to explicitly request alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. Once migration is complete, WQ_UNBOUND can be removed and unbound will become the implicit default. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-11-07drm/sched: Replace use of system_wq with system_percpu_wqMarco Crivellari
In the general workqueue implementation, 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. For more details see the Link tag below. 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") Use the successor of system_wq, system_percpu_wq, for the scheduler's default timeout_wq. system_wq will be removed in a few release cycles. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20251106150121.256367-1-marco.crivellari@suse.com
2025-11-07drm/vmwgfx: Restore Guest-Backed only cursor plane supportIan Forbes
The referenced fixes commit broke the cursor plane for configurations which have Guest-Backed surfaces but no cursor MOB support. Fixes: 965544150d1c ("drm/vmwgfx: Refactor cursor handling") Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20251103201920.381503-1-ian.forbes@broadcom.com
2025-11-07drm/vmwgfx: Use kref in vmw_bo_dirtyIan Forbes
Rather than using an ad hoc reference count use kref which is atomic and has underflow warnings. Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20251030193640.153697-1-ian.forbes@broadcom.com
2025-11-06drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZEIan Forbes
This data originates from userspace and is used in buffer offset calculations which could potentially overflow causing an out-of-bounds access. Fixes: 8ce75f8ab904 ("drm/vmwgfx: Update device includes for DX device functionality") Reported-by: Rohit Keshri <rkeshri@redhat.com> Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patch.msgid.link/20251021190128.13014-1-ian.forbes@broadcom.com
2025-11-07Merge tag 'mediatek-drm-fixes-20251105' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20251105 1. Disable AFBC support on Mediatek DRM driver 2. Add pm_runtime support for GCE power control Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20251105151443.3909-1-chunkuang.hu@kernel.org
2025-11-07Merge tag 'drm-misc-next-2025-11-05-1' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.19-rc1: UAPI Changes: - Add userptr support to ivpu. - Add IOCTL's for resource and telemetry data in amdxdna. Core Changes: - Improve some atomic state checking handling. - drm/client updates. - Use forward declarations instead of including drm_print.h - RUse allocation flags in ttm_pool/device_init and allow specifying max useful pool size and propagate ENOSPC. - Updates and fixes to scheduler and bridge code. - Add support for quirking DisplayID checksum errors. Driver Changes: - Assorted cleanups and fixes in rcar-du, accel/ivpu, panel/nv3052cf, sti, imxm, accel/qaic, accel/amdxdna, imagination, tidss, sti, panthor, vkms. - Add Samsung S6E3FC2X01 DDIC/AMS641RW, Synaptics TDDI series DSI, TL121BVMS07-00 (IL79900A) panels. - Add mali MediaTek MT8196 SoC gpu support. - Add etnaviv GC8000 Nano Ultra VIP r6205 support. - Document powervr ge7800 support in the devicetree. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/5afae707-c9aa-4a47-b726-5e1f1aa7a106@linux.intel.com
2025-11-06net: ravb: Use common defines for time stamping controlNiklas Söderlund
Instead of translating to/from driver specific flags for packet time stamp control use the common flags directly. This simplifies the driver as the translating code can be removed while at the same time making it clear the flags are not flags written to hardware registers. The change from a device specific bit-field track variable to the common enum datatypes forces us to touch the ravb_rx_rcar_hwstamp() in a non trivial way. To make this cleaner and easier to understand expand the nested conditions. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251104222420.882731-8-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: ravb: Break out Rx hardware timestampingNiklas Söderlund
Prepare for moving away from device specific bit-fields to track how to do hardware Rx timestamping to using net common enums by breaking out the timestamping to a helper function. This is done to create cleaner code and prepare for easier changes improving the hardware timestapming. There is no functional change. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251104222420.882731-7-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: rcar_gen4_ptp: Remove unused definesNiklas Söderlund
The driver specific flags to control packet time stamps have all been replaced by values from enum hwtstamp_tx_types and enum hwtstamp_rx_filters. Remove the driver specific flags as there are no more users. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251104222420.882731-6-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: rtsn: Use common defines for time stamping controlNiklas Söderlund
Instead of translating to/from driver specific flags for packet time stamp control use the common flags directly. This simplifies the driver as the translating code can be removed while at the same time making it clear the flags are not flags written to hardware registers. One thing to note is that the bit-wise and check in rtsn_rx() of RCAR_GEN4_RXTSTAMP_TYPE_V2_L2_EVENT is replaced with a not set check of HWTSTAMP_FILTER_NONE. This is okay as the bit of device specific event replaced was set for all modes except HWTSTAMP_FILTER_NONE. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251104222420.882731-5-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: rswitch: Use common defines for time stamping controlNiklas Söderlund
Instead of translating to/from driver specific flags for packet time stamp control use the common flags directly. This simplifies the driver as the translating code can be removed while at the same time making it clear the flags are not flags written to hardware registers. One thing to note is that the bit-wise and check in rswitch_rx() of RCAR_GEN4_RXTSTAMP_TYPE_V2_L2_EVENT is replaced with a not set check of HWTSTAMP_FILTER_NONE. This is okay as the bit of device specific event replaced was set for all modes except HWTSTAMP_FILTER_NONE. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251104222420.882731-4-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: rcar_gen4_ptp: Move control fields to usersNiklas Söderlund
The struct rcar_gen4_ptp_private provides two fields for convenience of its users, tstamp_tx_ctrl and tstamp_rx_ctrl. These fields are not used by the rcar_gen4_ptp driver itself but only by the drivers using it. Upcoming work will enable the RAVB driver currently only supporting gPTP on pre-Gen4 SoCs to use the Gen4 implementation as well. To facilitate this the convenience of having these fields in struct rcar_gen4_ptp_private becomes a problem as the RAVB driver already have it's own driver specific fields for the same thing. Move the fields from struct rcar_gen4_ptp_private to each driver using the Gen4 gPTP clocks own private data structures. There is no functional change. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20251104222420.882731-3-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-11-06net: rswitch: Move definition of S4 gPTP offsetNiklas Söderlund
The files rcar_gen4_ptp.{c,h} implements an abstraction of the gPTP support implemented together with different other IP blocks. The first device added which supported this was RSWITCH on R-Car S4. While doing so the RSWITCH R-Car S4 specific offset was added to the generic Gen4 gPTP header file. Move it to the RSWITCH driver to make it clear it only applies to this driver. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20251104222420.882731-2-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-20 02:32:47 +0000