summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-06-30drm/panthor: Interrupt group start/resumption if group_bind_locked() failsBoris Brezillon
group_bind_locked() can fail if the MMU block is stuck. This is normally a reset situation, but by the time we reset the GPU, we might have tried to resume a group that's not resident, which will probably trip out the FW. So let's avoid that by bailing out when group_bind_locked() returns an error. We don't even try to start more groups because the GPU will be reset anyway. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=7 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-10-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix a leak when a group is evicted before the tiler OOM is servicedBoris Brezillon
A group ref is tied to the pending tiler_oom_work, so we need to release it if the cancel was effective. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260623-panthor-signal-from-irq-v3-0-2ece396f8ee0@collabora.com?part=7 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-9-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Drop a needless check in panthor_fw_unplug()Boris Brezillon
panthor_fw_unplug() is only called if we at least managed to initialize the IRQ, so it's safe to drop the "is IRQ initialized" check. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-8-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix panthor_pwr_unplug()Boris Brezillon
We can't call panthor_pwr_irq_suspend() if the device is suspended, or this leads to a hang when the IOMEM region is accessed while the clks are disabled. Do what other sub-components do and conditionally call panthor_pwr_irq_suspend() if we know the PWR regbank block is accessible. Fixes: c27787f2b77f ("drm/panthor: Introduce panthor_pwr API and power control framework") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-7-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Don't overrule pending immediate ticks in sched_resume_tick()Boris Brezillon
We schedule immediate ticks when we need to process events on CSGs, but those immediate ticks don't change the resched_target because we want the other groups to stay scheduled for the remaining of the GPU timeslot they were given. Make sure these immediate ticks don't get overruled by a sched_queue_delayed_work() that would delay the tick execution. Fixes: 99820b4b7e50 ("drm/panthor: Make sure we resume the tick when new jobs are submitted") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=9 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Karunika Choo <karunika.choo@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-6-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix theoretical IOMEM access in suspended stateBoris Brezillon
In theory, our hardirq handler can be called while the device (and thus the panthor_irq) is suspended, because the IRQ line is shared. In practice though, in all the designs we've seen, the line is only shared within the GPU, and because sub-component suspend state is consistent (all-suspended or all-resumed), we shouldn't end up with an interrupt triggered while we're suspended. Fix the problem anyway, if nothing else, for our sanity. Fixes: 0b2d86670a84 ("drm/panthor: Rework panthor_irq::suspended into panthor_irq::state") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v4-0-3d2908912afa@collabora.com?part=1 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-5-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Fix potential invalid pointer deref in group_process_tiler_oom()Boris Brezillon
If heaps is an ERR_PTR(), panthor_heap_pool_put() will deref an invalid pointer. Make sure we set it to NULL in that case. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=2 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-4-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Keep the reset work disabled until everything is initializedBoris Brezillon
The reset work will sub-component reset helpers, which might not be ready if the reset happens during initialization, leading to NULL pointer dereferences or worse. Avoid that by keeping the reset work disabled while we're initializing those sub-components. Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=4 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-2-b67ed973fea6@collabora.com
2026-06-30drm/panthor: Always use the IRQ-safe variant when acquiring the fence lockBoris Brezillon
Since dma_fence objects can be shared with other subsystems, they may be accessed from hardirq context in those drivers, and we have to take that into account by also using the IRQ-safe variant when acquiring the lock. While at it, switch to the guard model. Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block") Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260625-panthor-signal-from-irq-v5-0-8836a74e0ef9@collabora.com?part=11 Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260625-panthor-misc-fixes-v1-1-b67ed973fea6@collabora.com
2026-06-30drm/arm/komeda: fix error handling for clk_prepare_enable() and callersGustavo Kenji Mendonça Kaneko
komeda_dev_resume() calls clk_prepare_enable() without checking the return value. If the clock fails to enable, the function returns 0 (success) while IRQs are enabled and IOMMU is connected on potentially unclocked hardware, causing undefined behavior on resume. Propagate the error from clk_prepare_enable() and fix all call sites in komeda_drv.c that previously ignored the return value of komeda_dev_resume(): - komeda_platform_probe(): if resume fails, jump to err_destroy_mdev (skipping the suspend call, since the clock was never enabled) - komeda_pm_resume(): propagate the error and skip drm_mode_config_helper_resume() on failure This issue was found by code review without access to Komeda hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko <kaneko.dev@pm.me> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260609130828.1066038-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-06-30drm/arm/malidp: use clk_bulk API in runtime PM resume and suspendGustavo Kenji Mendonça Kaneko
malidp_runtime_pm_resume() calls clk_prepare_enable() three times without checking the return value. If any clock fails to enable, the driver silently proceeds with unclocked hardware, leading to undefined behavior. Convert both the resume and suspend paths to use the clk_bulk API: clk_bulk_prepare_enable() in resume checks the return value and rolls back any successfully enabled clocks on failure; clk_bulk_disable_unprepare() in suspend keeps the two paths symmetric. This issue was found by code review without access to Mali DP hardware. Signed-off-by: Gustavo Kenji Mendonça Kaneko <kaneko.dev@pm.me> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260609130812.1065699-1-kaneko.dev@pm.me Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
2026-06-30gpu: nova-core: vbios: parse structs via zerocopyNicolás Antinori
Replace the unsafe `kernel::transmute::FromBytes` trait implementation for the `FalconUCodeDescV3`, `PcirStruct`, `BitHeader`, `BitToken`, `NpdeStruct`, `PciRomHeader`, `PmuLookupTableEntry` and `PmuLookupTableHeader` structs with the derivable `zerocopy::FromBytes` trait. This change eliminates the manual unsafe implementations in favor of a derivable trait. When this trait is derived, validity checks are performed at compile time to ensure that the type can safely implement `FromBytes`. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1241 Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com> Link: https://patch.msgid.link/20260629142007.269873-1-nico.antinori.7@gmail.com [acourbot: add `vbios:` prefix to commit title.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-30drm/virtio: fail init on display-info timeoutPengpeng Hou
virtio_gpu_init() sends GET_DISPLAY_INFO when scanouts are present and waits for display_info_pending to clear. If the response never arrives, the wait result is ignored and probe still succeeds. Return -ETIMEDOUT on display-info timeout. Because this happens after virtio_device_ready(), reset the device and tear down modesetting before using the existing vbuf and virtqueue cleanup path. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/735301/ [dmitry.osipenko@collabora.com: rebase on misc-next]
2026-06-30drm/virtio: bound EDID block reads to the response bufferBryam Vargas
virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected. Fixes: b4b01b4995fb ("drm/virtio: add edid support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patch.msgid.link/20260620-b4-disp-22bba7bf-v1-1-b95924cee742@proton.me
2026-06-30Merge drm/drm-next into drm-intel-nextJani Nikula
Sync with v7.2-rc1. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-30drm/sysfb: simpledrm: Validate mmap size against framebuffer sizeThomas Zimmermann
The size of the mmap'ed framebuffer could be smaller than the minimum required framebuffer size. Validate the resource size against the framebuffer size. Buggy firmware that triggers this check should be fixed up with a quirk on a case-by-case base. v3: - fix size checks (Sashiko) - improve error message for alignment check (Thierry) - do not store aligned size value Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Sashiko <sashiko-bot@kernel.org> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260625094509.157581-6-tzimmermann@suse.de
2026-06-30drm/sysfb: simpledrm: Improve stride validationThomas Zimmermann
Validate the computed stride against the maximum value INT_MAX. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 7bfa5c7b28d6 ("drm/simpledrm: Compute linestride with drm_format_info_min_pitch()") Cc: <stable@vger.kernel.org> # v6.1+ Link: https://patch.msgid.link/20260625094509.157581-5-tzimmermann@suse.de
2026-06-30drm/sysfb: simpledrm: Inline simplefb_get_validated_int()Thomas Zimmermann
The helper simplefb_get_validated_int() is only a wrapper around drm_sysfb_get_validated_int(). Inline the function into its callers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260625094509.157581-4-tzimmermann@suse.de
2026-06-30drm/sysfb: simpledrm: Improve panel-size validationThomas Zimmermann
Validate the panel size from the device-tree node against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail transparently on errors; do not warn. v3: - move comments to a more prominent place (Thierry) v2: - only use initialized values in debugging output (Sashiko) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 2a6d731a8f16 ("drm/simpledrm: Allow physical width and height configuration via panel node") Cc: Rayyan Ansari <rayyan@ansari.sh> Cc: <stable@vger.kernel.org> # v6.4+ Link: https://patch.msgid.link/20260625094509.157581-3-tzimmermann@suse.de
2026-06-30drm/sysfb: simpledrm: Improve framebuffer-size validationThomas Zimmermann
Validate the framebuffer size from the firmware against the limitations of struct drm_display_mode. The type only stores sizes in 16-bit fields. Fail probing on errors. v2: - remove unused function simplefb_get_validated_int0() (Sashiko) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Cc: <stable@vger.kernel.org> # v5.14+ Fixes: 11e8f5fd223b ("drm: Add simpledrm driver") Link: https://patch.msgid.link/20260625094509.157581-2-tzimmermann@suse.de
2026-06-30firmware: sysfb: Mark CONFIG_SYSFB_SIMPLEFB as deprecatedThomas Zimmermann
Mark CONFIG_SYSFB_SIMPLEFB as deprecated. Enabling it allows to run simpledrm and simplefb on EFI/VESA framebuffers. Doing this is discouraged in favor of using efidrm and vesadrm. v2: - resolve conflicting help texts (Sashiko) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patch.msgid.link/20260625065724.15794-1-tzimmermann@suse.de
2026-06-30drm/i915/bios: range check LFP Data Block panel_type2Jani Nikula
While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: 6434cf630086 ("drm/i915/bios: calculate panel type as per child device index in VBT") Cc: stable@vger.kernel.org # v6.0+ Cc: Animesh Manna <animesh.manna@intel.com> Cc: Ville Syrjälä <ville.syrjala@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> # v1 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260626140155.1389655-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-30Merge drm/drm-next into drm-misc-nextThomas Zimmermann
Backmerging to get drm-misc-next to v7.2-rc1. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2026-06-30drm/i915/vrr: require valid min/max vfreq for VRRJani Nikula
Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: 117cd09ba528 ("drm/i915/display/dp: Compute VRR state in atomic_check") Cc: stable@vger.kernel.org # v5.12+ Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-30drm/i915/hdcp: require monotonically increasing seq_num_vJani Nikula
The HDCP 2.2 specification requires the seq_num_v to be monotonically increasing, and repeated seq_num_v needs to be treated as an integrity failure. Make it so. For the first message, seq_num_v must be zero, and is already checked. We can only check for less-than-or-equal for the subsequent messages, where hdcp2_encrypted is true. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication") Cc: stable@vger.kernel.org # v5.2+ Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 58a224375c81179b52558c53d8857b93196d2687) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-06-30drm/i915/hdcp: check streams[] bounds before overflowJani Nikula
The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data") Cc: stable@vger.kernel.org # v5.12+ Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-06-30drm/i915: Return NULL on error in active_instanceJoonas Lahtinen
Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: bfaae47db3c0 ("drm/i915: make lockdep slightly happier about execbuf.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Simona Vetter <simona.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v5.13+ Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/20260624090940.74840-1-joonas.lahtinen@linux.intel.com (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-06-30drm/lima: call drm_mm_init() with a valid allocation rangeHenrik Grimler
lima_vm_create() is currently run before va_start and va_end are set up, meaning they are both 0. lima_vm_create() runs drm_mm_init() with them as arguments for the allocator, and if DRM_DEBUG_MM is enabled the DRM_MM_BUG_ON check in drm_mm_init then fires, as seen here on exynos4412-odroid-u2: [ 1.736297] ------------[ cut here ]------------ [ 1.740370] kernel BUG at drivers/gpu/drm/drm_mm.c:931! [ 1.745574] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 1.750697] Modules linked in: [ 1.753734] CPU: 0 UID: 0 PID: 41 Comm: kworker/u16:1 Not tainted 7.0.10-postmarketos-exynos4 #11 PREEMPT [ 1.763372] Hardware name: Samsung Exynos (Flattened Device Tree) [ 1.769446] Workqueue: events_unbound deferred_probe_work_func [ 1.775261] PC is at drm_mm_init+0x9c/0xa4 [ 1.779339] LR is at lima_vm_create+0x144/0x17c [ ... ] Fix the issue by moving the lima_vm_create() call after va_start and va_end are set up. Fixes: a1d2a6339961 ("drm/lima: driver for ARM Mali4xx GPUs") Signed-off-by: Henrik Grimler <henrik.grimler@axis.com> Signed-off-by: Qiang Yu <yuq825@gmail.com> Link: https://patch.msgid.link/20260601-lima-alloc-fix-v1-1-16d3f3b7b780@axis.com
2026-06-30ttm/pool: Use sentinels in debugfsMario Limonciello
The values in the `page_pool_shrink` debugfs file should recognize the sentinels rather than causing an underflow. Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5218 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260427162253.682415-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <superm1@kernel.org>
2026-06-29drm/amd/display: use DisplayID panel type in dm_set_panel_typeChenyu Chen
Wire up the newly parsed panel_type from drm_display_info into amdgpu_dm's panel type detection path. When neither the AMD VSDB nor DPCD determines the panel type, fall back to the DisplayID Display Device Technology field to set PANEL_TYPE_LCD or PANEL_TYPE_OLED accordingly. Also expose LCD to userspace via the panel_type connector property. Assisted-by: Copilot:Claude-Opus-4.6 Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260526030254.1460480-4-chen-yu.chen@amd.com Signed-off-by: Mario Limonciello <superm1@kernel.org>
2026-06-29drm/edid: parse panel type from DisplayID 2.x Display ParametersChenyu Chen
Parse the Display Parameters Data Block (tag 0x21) defined in DisplayID v2.1a Section 4.2.6. Extract the Display Device Technology field from the color depth and device technology byte, which indicates whether the panel uses LCD or OLED technology. Add a panel_type field to struct drm_display_info and populate it during DisplayID iteration so downstream drivers can use it for panel-type-dependent behavior. Add DRM_MODE_PANEL_TYPE_LCD to the UAPI panel type property alongside the existing OLED value. Assisted-by: Copilot:Claude-Opus-4.6 Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260526030254.1460480-3-chen-yu.chen@amd.com Signed-off-by: Mario Limonciello <superm1@kernel.org>
2026-06-29drm/edid: extract base section header processing into helperChenyu Chen
Extract the DisplayID base section header logging and non_desktop detection from update_displayid_info() into a dedicated helper, drm_displayid_process_base_section_header(). Remove the break so the iterator walks through all data blocks, preparing for future patches that will parse additional block types within the loop. The helper is called only once for the base section via a base_section_header_processed flag. Since version and primary_use are only captured from the base section, and extension sections carry a primary use of zero per spec, the non_desktop logic is unaffected. No functional change. Assisted-by: Copilot:Claude-Opus-4.6 Signed-off-by: Chenyu Chen <chen-yu.chen@amd.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260526030254.1460480-2-chen-yu.chen@amd.com Signed-off-by: Mario Limonciello <superm1@kernel.org>
2026-06-29drm/xe/hw_engine: Fix double-free of managed BO in error pathShuicheng Lin
The error path in hw_engine_init() explicitly frees a BO allocated with xe_managed_bo_create_pin_map() via xe_bo_unpin_map_no_vm(). Since the managed BO already has a devm cleanup action registered, this causes a double-free when devm unwinds during probe failure. Remove the explicit free and let devm handle it, consistent with all other xe_managed_bo_create_pin_map() callers. Fixes: 0e1a47fcabc8 ("drm/xe: Add a helper for DRM device-lifetime BO create") Assisted-by: Claude:claude-opus-4.6 Reviewed-by: Zongyao Bai <zongyao.bai@intel.com> Link: https://patch.msgid.link/20260626210631.3887291-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-06-29drm/xe/userptr: Drop bogus static from finish in force_invalidateShuicheng Lin
The local "finish" pointer in xe_vma_userptr_force_invalidate() is unconditionally written before each read, so the static storage class serves no purpose. Worse, it makes the variable a process-wide shared slot: the function's per-VM asserts do not exclude concurrent callers on different VMs, so two such callers can race on the slot and take the wrong if (finish) branch. The function is gated by CONFIG_DRM_XE_USERPTR_INVAL_INJECT (developer/test option, default n), so production builds are unaffected. Drop the static. Fixes: 18c4e536959e ("drm/xe/userptr: Convert invalidation to two-pass MMU notifier") Assisted-by: Claude:claude-opus-4.7 Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Zongyao Bai <zongyao.bai@intel.com> Link: https://patch.msgid.link/20260625224452.3243231-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-06-29drm/xe/userptr: Hold notifier_lock for write on inject test pathShuicheng Lin
When CONFIG_DRM_XE_USERPTR_INVAL_INJECT=y, xe_pt_svm_userptr_pre_commit() runs vma_check_userptr() with the svm notifier_lock taken for read. The test injection causes vma_check_userptr() to call xe_vma_userptr_force_invalidate(), which feeds into xe_vma_userptr_do_inval() with drm_gpusvm_ctx.in_notifier=true. That flag tells drm_gpusvm_unmap_pages() the caller already holds notifier_lock for write and only asserts the mode. Because the caller actually holds it for read, the assertion fires: WARNING: drivers/gpu/drm/drm_gpusvm.c:1669 at \ drm_gpusvm_unmap_pages+0xd4/0x130 [drm_gpusvm_helper] Call Trace: xe_vma_userptr_do_inval+0x40d/0xfd0 [xe] xe_vma_userptr_invalidate_pass1+0x3e6/0x8d0 [xe] xe_vma_userptr_force_invalidate+0xde/0x290 [xe] vma_check_userptr.constprop.0+0x1c6/0x220 [xe] xe_pt_svm_userptr_pre_commit+0x6a3/0xc60 [xe] ... xe_vm_bind_ioctl+0x3a0a/0x4480 [xe] Acquire notifier_lock for write in pre-commit when the inject Kconfig is enabled, via new helpers xe_pt_svm_userptr_notifier_lock()/_unlock(). Rename xe_svm_assert_held_read() to xe_svm_assert_held_read_or_inject_write() so it asserts the correct mode under each build configuration. Production builds (CONFIG_DRM_XE_USERPTR_INVAL_INJECT=n) keep the existing read-mode behavior bit-for-bit. Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Assisted-by: Claude:claude-opus-4.7 Cc: Matthew Auld <matthew.auld@intel.com> Cc: Zongyao Bai <zongyao.bai@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260625215615.3016892-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
2026-06-29gpu: nova-core: falcon: store bar and dev in falconTim Kovalenko
Store the bound device and `BAR0` mapping in `Falcon` instead of passing them through every `Falcon` operation. This simplifies the `Falcon` API and removes repeated `dev`/`bar` plumbing from reset, load, boot, mailbox, DMA, and GSP/FSP-specific Falcon helpers. `FalconHal` now receives a reference to a `Falcon` and uses its methods and members instead of passing them individually. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/Storing.20driver-bound.20references.20into.20sub-devices/near/599137882 Signed-off-by: Tim Kovalenko <tim.kovalenko@proton.me> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260625-drm-bar-refactor-v2-1-9db6b890d92e@proton.me Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-06-29gpu: drm: nova: depend on nova-core and use its symbolsAlexandre Courbot
Make nova-core a build dependency of nova-drm, so its crate metadata is available and up-to-date when the latter is built. This is intended to be a workaround until the build system supports Rust cross-crate dependencies natively. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-4-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29gpu: nova-core: emit Rust metadata for nova-drmAlexandre Courbot
Emit nova-core's crate metadata (libnova_core.rmeta) so that nova-drm can import nova-core's types and functions at compile time. This is intended to be a workaround until the build system supports Rust cross-crate dependencies natively. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-3-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29gpu: nova-core: export Rust symbols for nova-drmAlexandre Courbot
Export nova-core's Rust symbols so nova-drm can resolve references to it when loaded as a module. This is done by generating declarations and EXPORT_SYMBOL_RUST_GPL() calls for Rust symbols referenced by nova-drm, and compiling them into the module as `nova_core_exports.o`. `nova_core_exports.o` declares every Rust symbol as `extern int`. Running `gendwarfksyms` on it would compute CRCs from those placeholder types instead of the real Rust ones, so make MODVERSIONS use this shim only for the export list, and derive CRCs from `nova_core.o`. This patch is intended to be a workaround until the build system supports Rust cross-crate dependencies natively. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-2-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29gpu: build nova-core and nova-drm from drivers/gpu/MakefileAlexandre Courbot
A dependency between nova-core and nova-drm is about to be introduced, which requires nova-core to be built first. As this is not easily doable from separate directories, move both build targets to the first common parent, `drivers/gpu/Makefile`. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260622-nova-exports-v5-1-6191773fc977@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-29drm/i915/hdcp: require monotonically increasing seq_num_vJani Nikula
The HDCP 2.2 specification requires the seq_num_v to be monotonically increasing, and repeated seq_num_v needs to be treated as an integrity failure. Make it so. For the first message, seq_num_v must be zero, and is already checked. We can only check for less-than-or-equal for the subsequent messages, where hdcp2_encrypted is true. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication") Cc: stable@vger.kernel.org # v5.2+ Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-29drm/i915/hdcp: check streams[] bounds before overflowJani Nikula
The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo <martin.hodo@intel.com> Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data") Cc: stable@vger.kernel.org # v5.12+ Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-29Revert "drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TG"Ankit Nautiyal
This reverts commit 4f1cab2e4863d96ce13b8d94151f4848e38c3d5b. Allowing SCL=0 on platforms with always-on VRR timing generator is causing underruns and other issues on PTL in some cases. SCL still needs to be non-zero in certain scenarios. Revert for now until this is better understood. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260622101736.2389991-1-ankit.k.nautiyal@intel.com
2026-06-28Merge tag 'v7.2-rc1' into drm-rust-nextDanilo Krummrich
Merge v7.2-rc1 into drm-rust-next to start the next cycle. Devres now requires T: 'static, which conflicts with shmem::Object using Devres<SGTableMap<T, C>> without that bound. Resolve by adding 'static as a supertrait to DriverObject and DeviceContext, which does not restrict any current use cases since DriverObject is always implemented on owned, refcounted types and DeviceContext is a sealed marker trait with only unit-type implementors. If DriverObject (or DeviceContext) ever becomes lifetime-parameterized (e.g. via a GAT for TTM backed objects), the 'static supertrait can be relaxed at that point. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-06-26Merge tag 'drm-fixes-2026-06-27' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "These are just the fixes from our fixes branch, all pretty small and scattered. sysfb: - drm/sysfb truncation and alignment fixes edid: - fix edid OOB read in tile parsing - increase displayid topology id to correct size nouveau: - fix error handling paths in nouveau amdxdna: - get_bo_info fix ivpu: - fix leak when error handling in ivpu" * tag 'drm-fixes-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel: drm/sysfb: Avoid truncating maximum stride drm/sysfb: Return errno code from drm_sysfb_get_visible_size() drm/sysfb: Avoid possible truncation with calculating visible size drm/sysfb: Do not page-align visible size of the framebuffer drm/edid: fix OOB read in drm_parse_tiled_block() drm/nouveau: fix reversed error cleanup order in ucopy functions drm/nouveau/acr: fix missing nvkm_done() in error path of nvkm_acr_oneinit() accel/amdxdna: Use caller client for debug BO sync drm/displayid: fix Tiled Display Topology ID size accel/ivpu: fix HWS command queue leak on registration failure
2026-06-26Merge tag 'drm-next-2026-06-27' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm merge window fixes from Dave Airlie: "This is the merge window fixes from our next tree, i915/xe and amdgpu make up all of it. I've got a separate fixes pull from our fixes branch arriving after this. i915: - Fix corrupted display output on GLK, #16209 - Add missing Spectre mitigation for parallel submit IOCTL - MTL+ fix for DP resume - clear CRTC blobs after dropping refs - fix sharpness filter on DP MST xe: - Set TTM beneficial order to 9 in Xe - Several error path cleanups - Fix TDR for unstarted jobs on kernel queues - Several TLB invalidation fixes related to suspending LR queues - Some small RAS fixes - Multi-queue suspend fix for LR queues - Revert inclusion of NVL_S firmware amdgpu: - devcoredump fixes - SMU15 fix - Various irq put/get imbalance cleanup fixes - 8K panel fix - DCN3.5 fix - lockdep fix - Cleaner shader sysfs IB overflow fix - Async flip fixes - GET_MAPPING_INFO fix - CP_GFX_SHADOW fix - Ctx pstate handling fix - GTT bo move handling fixes - Old UVD BO placement fixes - GC9 mode2 reset fix - IH6.1 version fix - Soft IH ring fix amdkfd: - Fix doorbell/mmio double unpin on free - CRIU fixes - SMI event fixes - Sysfs teardown fix - Various boundary checking fixes - Various error checking fixes - SVM fix" * tag 'drm-next-2026-06-27' of https://gitlab.freedesktop.org/drm/kernel: (52 commits) drm/i915/cdclk: Fix up CDCLK_FREQ_DECIMAL without a full PLL re-enable drm/i915/gem: Add missing nospec on parallel submit slot drm/amdgpu: Use system unbound workqueue for soft IH ring amdgpu/ih6.1: Fix minor version drm/amdkfd: Use exclusive bounds for SVM split alignment checks drm/amdgpu/gfx9: Fix Ring and IB test fail after mode2 drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't at 0 (v2) drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT drm/amdgpu: Respect placement requirements in amdgpu_gtt_mgr functions drm/amdgpu: Fix context pstate override handling drm/amdkfd: Use memdup_array_user to copy data from/to user space at kfd ioctls drm/amdkfd: check find_first_zero_bit before __set_bit on kfd->doorbell_bitmap drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl drm/amdgpu: fix recursive ww_mutex acquire in amdgpu_devcoredump_format drm/amdgpu: convert amdgpu_vm_lock_by_pasid() to drm_exec drm/amdgpu: Don't use UTS_RELEASE directly drm/amdkfd: Fix NULL deref during sysfs teardown drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO ...
2026-06-26drm/i915: Refactor generic_handle_irq_safe() error messagesJonathan Cavitt
Refactor all error messages resulting from generic_handle_irq_safe() failures in I915 for clarity. v2: - Use drm_err_ratelimited() correctly (jcavitt) v3: - Use xe_err_ratelimited() instead (Jadav) - Split into patch series (jcavitt) v4: - Use suggested phrasing (Wajdeczko) v5: - s/PTR_ERR/ERR_PTR (jcavitt) Suggested-by: Raag Jadav <raag.jadav@intel.com> Suggested-by: Michal Wajdeczko <Michal.Wajdeczko@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260623202310.1023770-1-jonathan.cavitt@intel.com
2026-06-26drm/bridge: of-display-mode-bridge: Fix missing static const for the bridge ↵Damon Ding
funcs Add static qualifier for of_display_mode_bridge_funcs to resolve the sparse warning: drivers/gpu/drm/bridge/of-display-mode-bridge.c:54:25: sparse: sparse: symbol 'of_display_mode_bridge_funcs' was not declared. Should it be static? Also mark the structure const as required by devm_drm_bridge_alloc() parameter type constraints. Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606170744.FUStcWaB-lkp@intel.com/ Signed-off-by: Damon Ding <damon.ding@rock-chips.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://patch.msgid.link/20260617080755.186368-1-damon.ding@rock-chips.com Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
2026-06-26drm/{i915, xe}: move intel_hpd_cancel_work() to ↵Jani Nikula
intel_display_driver_remove_noirq() intel_hpd_cancel_work() gets called before intel_display_driver_remove_noirq(). Move it there. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/6be8d033a6c8d0038dc14100d3ee6612d6204770.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-06-26drm/{i915, xe}: move opregion cleanup to intel_display_driver_remove_nogem()Jani Nikula
The intel_opregion_cleanup() call should really be in display. Move it at the end of intel_display_driver_probe_noirq(). For xe, this is a completely non-functional change now that the noirq/nogem cleanup calls are in the right order. For i915, this only changes the relative order of intel_opregion_cleanup() and i915_perf_fini(), which should be of no consequence. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/8ccd49a5945e0560ba22079d686db1268e8e9f7f.1781549229.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-17 11:55:33 +0000