summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-07-22drm/panel: simple: Add Kyocera tcg070wvlq panelHeiko Schocher
Commit 922fb2db0287 ("dt-bindings: display: simple: Add Kyocera tcg070wvlq panel") added the compatible string for the Kyocera tcg070wvlq panel to the devicetree bindings documentation (panel-simple.yaml), but the corresponding entry was not added to the panel-simple driver. Add the missing compatible entry to the driver. Signed-off-by: Heiko Schocher <hs@nabladev.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260721041935.757240-1-hs@nabladev.com
2026-07-22drm/panel: osd101t2587: migrate to newer mipi_dsi* functionsRobert-Andrei Mercea
Migrate osd101t2587-53ts panel driver from deprecated mipi_dsi* functions to their *_multi variants for improved error handling, as specified in the GPU subsystem TODO list. Link: https://docs.kernel.org/gpu/todo.html#transition-away-from-using-deprecated-mipi-dsi-functions Signed-off-by: Robert-Andrei Mercea <robertandreimercea@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260720115126.666363-1-robertandreimercea@gmail.com
2026-07-22drm/i915/dp: set VSC_SDP MSA delegation only for capable sinksChaitanya Kumar Borah
Per DP 1.4a section 2.2.4.3, the MSA MISC1 VSC_SDP bit signals that the sink should defer colorimetry to the VSC SDP. It should only be set when the sink advertises DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED and a VSC SDP with pixel encoding/colorimetry payload will actually be sent. Fold the colorimetry_support check into intel_dp_needs_vsc_colorimetry() so both intel_ddi_set_dp_msa() and intel_dp_compute_vsc_sdp() share a single consistent gate. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Pranay Samala <pranay.samala@intel.com> Link: https://patch.msgid.link/20260709113951.3557968-3-chaitanya.kumar.borah@intel.com
2026-07-22drm/i915/dp: s/intel_dp_needs_vsc_sdp/intel_dp_needs_vsc_colorimetryChaitanya Kumar Borah
The function answers whether a VSC SDP with colorimetry and pixel encoding payload is required by the content being displayed. Rename it to reflect that. No functional change intended. Assisted-by: GitHub_Copilot:claude-sonnet-4.6 Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Pranay Samala <pranay.samala@intel.com> Link: https://patch.msgid.link/20260709113951.3557968-2-chaitanya.kumar.borah@intel.com
2026-07-22drm/pagemap: Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATIONMatthew Brost
HPAGE_PMD_SHIFT expands to BUILD_BUG() when CONFIG_PGTABLE_HAS_HUGE_LEAVES is not set, causing a compile error when both CONFIG_TRANSPARENT_HUGEPAGE and CONFIG_HUGETLB_PAGE are disabled: drivers/gpu/drm/drm_pagemap.c:480:12: error: call to '__compiletime_assert_458' declared with 'error' attribute: BUILD_BUG failed 480 | order = HPAGE_PMD_ORDER; | ^ include/linux/huge_mm.h:117:26: note: expanded from macro 'HPAGE_PMD_ORDER' 117 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) | ^ include/linux/huge_mm.h:113:28: note: expanded from macro 'HPAGE_PMD_SHIFT' 113 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) Define DRM_PAGEMAP_PMD_ORDER, which maps to HPAGE_PMD_ORDER when CONFIG_ARCH_ENABLE_THP_MIGRATION is enabled and to -1 otherwise. This is safe because all code paths that use DRM_PAGEMAP_PMD_ORDER are reachable only when CONFIG_ARCH_ENABLE_THP_MIGRATION is enabled. Fixes: 139ab31aea8a ("drm/pagemap: Correct cpages calculation for migrate_vma_setup") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202607201914.LpAGsbXs-lkp@intel.com/ Cc: Jan Stancek <jstancek@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Jan Stancek <jstancek@redhat.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260721223244.1102276-1-matthew.brost@intel.com
2026-07-22drm/pagemap: Clear driver-provided PFNs from migration PFN arrayMatthew Brost
DRM pagemap overloads the migration PFN array to store driver-provided PFNs before calling migrate_vma_*() to finalize the migration. If an error occurs during the incremental copy phase, the migration PFN entries are reverted to their original state. After reverting the device-folio mutations, clear any remaining driver-provided PFNs to avoid confusing the migrate_vma_*() helpers. Also clear any driver-provided PFNs if populate_devmem_pfn() fails, as a precaution against stale entries being interpreted as migration PFNs. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: 3902846af36b ("drm/pagemap Fix error paths in drm_pagemap_migrate_to_devmem") Fixes: ec265e1f1cfc ("drm/pagemap: Support source migration over interconnect") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260721204353.1082632-1-matthew.brost@intel.com
2026-07-22drm/i915/display: Ensure a non-zero safe window from PTL onwardsAnkit Nautiyal
From PTL onwards, the set context latency can be in the vactive region, letting the safe window start some lines before the vblank start. The DSB waits on this safe window instead of vblank (bits [15:14] select the safe window signal from the DPT unit to start the DMA engine). With modes that have a smaller vblank region, the computed guardband is clamped to the vblank length, making the undelayed and delayed vblank coincide. If the SCL is also 0, the 'safe window' becomes effectively 0, and the DSB configured to wait for it gets stalled, since the hardware never signals the safe window, leading to: *ERROR* [CRTC:159:pipe A] flip_done timed out *ERROR* [CRTC:159:pipe A] DSB 0 timed out waiting for idle Keep the set context latency at a minimum of 1 to avoid this. v2: Fix the bit numbers and correct the commit message. (Chaitanya) Fixes: 4a68c7516c57 ("drm/i915/dsb: Use safe window path when VRR TG is used") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Assisted-by: GitHub-Copilot:Claude-Opus-4.8 Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/20260722062449.1166411-1-ankit.k.nautiyal@intel.com
2026-07-22drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffersSatyanarayana K V P
CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe] xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe] xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm] ttm_bo_release+0x29e/0x2d0 [ttm] ttm_bo_fini+0x39/0x70 [ttm] xe_gem_object_free+0x1f/0x30 [xe] drm_gem_object_free+0x1d/0x40 ttm_bo_vm_close+0x5f/0x90 [ttm] remove_vma+0x2c/0x70 tear_down_vmas+0x63/0xf0 exit_mmap+0x20d/0x3f0 __mmput+0x45/0x170 mmput+0x31/0x40 do_exit+0x2ba/0xac0 do_group_exit+0x2d/0xb0 __x64_sys_exit_group+0x18/0x20 x64_sys_call+0x14a0/0x2390 do_syscall_64+0xdd/0x640 ? count_memcg_events+0xea/0x240 ? handle_mm_fault+0x1ec/0x2f0 Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721052215.2267228-2-satyanarayana.k.v.p@intel.com (cherry picked from commit 1ae415a6eefe5004954a1d352b1718faca8844ef) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-22drm/i915/hdcp: Make hdcp2_encrypted and hdcp_encrypted mutually exclusiveSuraj Kandpal
With introduction of force_hdcp14 we can now for HDCP 1.4 by passing HDCP 2.2 authentication but In MST, _intel_hdcp_disable() and _intel_hdcp2_disable() can return early when there are still other streams active on the port (num_streams > 0), leaving the per-connector hdcp_encrypted / hdcp2_encrypted flag stale. If the same connector is later re-enabled with the other HDCP version (e.g. HDCP 1.4 via force_hdcp14 after a prior HDCP 2.2 session on that connector) the stale flag from the previous protocol survives. intel_hdcp_disable() then picks the wrong branch on the next disable causing the following splat. xe 0000:00:02.0: [drm] drm_WARN_ON(!(intel_de_read(display, ((((&(display)->info.__runtime_info)->ip.ver) >= 12) ? ((const i915_reg_t){ .reg = (((0x664B4) + (cpu_transcoder) * ((0x665B4) - (0x664B4)))) }) : ((const i915_reg_t){ .reg = ((((const u32 []){ 0x66800, 0x66500, 0x66600, 0x66700, 0x66A00, 0x66900 })[(port)]) + (0xB4)) }))) & ((u32)(((int)sizeof(struct {_Static_assert(!(__builtin_choose_expr((sizeof(int) == sizeof(*(8 ? ((void *)((long)((20) >= (sizeof(u32) * 8)) * 0l)) : (int *)8))), (20) >= (sizeof(u32) * 8), false)), "const_true((20) >= BITS_PER_TYPE(u32))" " is true");})) + ((((1ULL))) << (20)))))) WARNING: drivers/gpu/drm/i915/display/intel_hdcp.c:1969 at _intel_hdcp2_disable+0x4bf/0x520 [xe], CPU#2: kms_content_pro/101318 Modules linked in: xe vfio_pci_core vfio_iommu_type1 vfio iommufd xt_multiport snd_hda_codec_intelhdmi snd_hda_codec_hdmi drm_gpuvm drm_gpusvm_helper drm_buddy gpu_sched drm_ttm_helper ttm drm_suballoc_helper drm_exec drm_display_helper cec rc_core drm_kunit_helpers kunit i2c_algo_bit xt_conntrack xt_MASQUERADE bridge stp llc nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat x_tables nf_tables xfrm_user xfrm_algo overlay cpuid cmdlinepart spi_nor mei_gsc_proxy mtd intel_rapl_msr wmi_bmof intel_uncore_frequency intel_uncore_frequency_common x86_pkg_temp_thermal intel_powerclamp coretemp snd_intel_dspcfg aesni_intel snd_hda_codec gf128mul snd_hda_core snd_hwdep r8169 snd_pcm intel_cstate snd_timer i2c_i801 i2c_mux snd spi_intel_pci processor_thermal_device_pci realtek video e1000e spi_intel i2c_smbus soundcore phy_package processor_thermal_device processor_thermal_wt_hint mei_me platform_temperature_control processor_thermal_soc_slider idma64 mei processor_thermal_rfim processor_thermal_rapl intel_ish_ipc intel_rapl_common intel_ishtp thunderbolt processor_thermal_wt_req processor_thermal_power_floor intel_vpu processor_thermal_mbox igen6_edac wmi sunrpc kvm_intel binfmt_misc kvm irqbypass int3403_thermal int340x_thermal_zone intel_skl_int3472_tps68470 tps68470_regulator intel_pmc_core clk_tps68470 acpi_tad int3400_thermal intel_hid pmt_telemetry acpi_thermal_rel sparse_keymap pmt_discovery pinctrl_intel_platform pmt_class intel_pmc_ssram_telemetry intel_pmc_pwrm_telemetry intel_skl_int3472_discrete intel_skl_int3472_common acpi_pad intel_vsec nls_iso8859_1 dm_multipath msr fuse efi_pstore autofs4 [last unloaded: xe_live_test] CPU: 2 UID: 0 PID: 101318 Comm: kms_content_pro Kdump: loaded Tainted: G U L N 7.2.0-rc2-lgci-xe-xe-5389-67aa8ad5c4c59cd1a-debug+ #1 PREEMPT(lazy) Tainted: [U]=USER, [L]=SOFTLOCKUP, [N]=TEST Hardware name: Intel Corporation Panther Lake Client Platform/PTL-UH LP5 T3 RVP1, BIOS PTLPFWI1.R00.3514.D01.2512291130 12/29/2025 RIP: 0010:_intel_hdcp2_disable+0x4c9/0x520 [xe] Code: 85 ff 74 04 48 8b 7f 08 4c 8b 7f 50 4d 85 ff 74 23 e8 5b 80 df e0 48 89 c6 48 8d 3d b1 f7 ba ff 48 c7 c1 a0 27 6a a1 4c 89 fa <67> 48 0f b9 3a e9 c9 fc ff ff 4c 8b 3f eb d8 e8 33 45 4e e1 4c 89 RSP: 0018:ffffc900027bf738 EFLAGS: 00010246 RAX: ffffffffa16bd4f1 RBX: ffff8881a1e69000 RCX: ffffffffa16a27a0 RDX: ffff8881c7b1b190 RSI: ffffffffa16bd4f1 RDI: ffffffffa100de30 RBP: ffffc900027bf7b0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88844397a000 R13: ffff88844397a000 R14: ffff88817f7d2000 R15: ffff8881c7b1b190 FS: 0000774e9299dbc0(0000) GS:ffff8884eb36c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000774e94bc7220 CR3: 00000002166c1002 CR4: 0000000108f72ef0 PKRU: 55555554 Call Trace: <TASK> ? intel_hdcp_update_value+0x7d/0x260 [xe] intel_hdcp_disable+0x118/0x130 [xe] intel_hdcp_update_pipe+0x175/0x1b0 [xe] ? intel_initial_watermarks+0x20/0x60 [xe] intel_ddi_update_pipe+0x44/0xb0 [xe] intel_pre_update_crtc+0x3bc/0x410 [xe] skl_commit_modeset_enables+0x1a7/0x890 [xe] ? icl_sagv_pre_plane_update+0x6c/0xf0 [xe] intel_atomic_commit_tail+0x114b/0x20a0 [xe] ? lock_release+0xd0/0x2a0 intel_atomic_commit+0x2ff/0x350 [xe] ? intel_atomic_commit+0x2ff/0x350 [xe] drm_atomic_commit+0xaf/0xf0 ? __pfx___drm_printfn_info+0x10/0x10 drm_mode_atomic_ioctl+0xcb5/0xf60 ? drm_mode_atomic_ioctl+0x8a8/0xf60 ? drm_mode_atomic_ioctl+0x604/0xf60 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xb3/0x120 drm_ioctl+0x2db/0x5a0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x51/0x80 ? __pm_runtime_resume+0x5b/0x90 ? xe_pm_runtime_get_ioctl+0x61/0x150 [xe] xe_drm_ioctl+0x64/0xb0 [xe] __x64_sys_ioctl+0xa5/0x100 x64_sys_call+0x1250/0x26e0 do_syscall_64+0x103/0x6d0 ? __task_pid_nr_ns+0xc0/0x290 ? trace_hardirqs_on_prepare+0xcb/0xf0 ? do_syscall_64+0x34/0x6d0 ? fred_entry_from_user+0x92/0x140 ? trace_hardirqs_on+0x22/0xe0 ? do_syscall_64+0xb8/0x6d0 fred_entry_from_user+0x92/0x140 asm_fred_entrypoint_user+0x41/ Ensure the two flags are mutually exclusive at every successful enable: after intel_hdcp_auth() succeeds. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Tested-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com> Reviewed-by: Santhosh Reddy Guddati <santhosh.reddy.guddati@intel.com> Link: https://patch.msgid.link/20260717034734.477591-1-suraj.kandpal@intel.com
2026-07-21drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffersSatyanarayana K V P
CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> xe_migrate_ccs_rw_copy_clear+0x98/0x120 [xe] xe_sriov_vf_ccs_detach_bo+0x2c/0x60 [xe] xe_ttm_bo_delete_mem_notify+0xc8/0xe0 [xe] ttm_bo_cleanup_memtype_use+0x26/0x80 [ttm] ttm_bo_release+0x29e/0x2d0 [ttm] ttm_bo_fini+0x39/0x70 [ttm] xe_gem_object_free+0x1f/0x30 [xe] drm_gem_object_free+0x1d/0x40 ttm_bo_vm_close+0x5f/0x90 [ttm] remove_vma+0x2c/0x70 tear_down_vmas+0x63/0xf0 exit_mmap+0x20d/0x3f0 __mmput+0x45/0x170 mmput+0x31/0x40 do_exit+0x2ba/0xac0 do_group_exit+0x2d/0xb0 __x64_sys_exit_group+0x18/0x20 x64_sys_call+0x14a0/0x2390 do_syscall_64+0xdd/0x640 ? count_memcg_events+0xea/0x240 ? handle_mm_fault+0x1ec/0x2f0 Fixes: 864690cf4dd6 ("drm/xe/vf: Attach and detach CCS copy commands with BO") Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260721052215.2267228-2-satyanarayana.k.v.p@intel.com
2026-07-21gpu: nova-core: fsp: limit FSP receive message allocation sizeEliot Courtney
Currently, the FSP receive message code will try to allocate whatever was sent without checking it at all. But the actual size allowed is limited to 1024 anyway, so reject any messages over that size as bogus. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260703-blackwell-fixes-v2-1-8e3d8bc32bb9@nvidia.com [acourbot: use `SZ_1K` constant for size.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-07-21drm/i915/bw: Fix spelling mistake "threshod" -> "threshold"Colin Ian King
There is a spelling mistake in a drm_dbg_kms message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20260720161630.326016-1-colin.i.king@gmail.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-21drm: Send per-connector hotplug eventsNicolas Frattaroli
Try to send per-connector hotplug events as often as possible, rather than connector-less global hotplug events. This does result in more hotplug events if multiple connectors changed at the same time, but give userspace more actionable information. Since the hotplug event needs to be sent outside of the mode_config mutex to avoid a deadlock, the drm_client_dev_hotplug() call is split off from the drm_sysfs_(connector_)?hotplug_event calls. Co-developed-by: Marius Vlad <marius.vlad@collabora.com> Signed-off-by: Marius Vlad <marius.vlad@collabora.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260526-hot-plug-passup-v10-2-f62351a9ea3e@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-07-21drm/vmwgfx: Validate vmw_surface_metadata::array_sizeIan Forbes
This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available. Fixes: 504901dbb0b5 ("drm/vmwgfx: Refactor surface_define to use vmw_surface_metadata") Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com> Cc: stable@vger.kernel.org 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/20260623193314.506257-1-ian.forbes@broadcom.com
2026-07-21drm/vc4: Prevent shader BO mappings from becoming writableLinmao Li
vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects. Fixes: 463873d57014 ("drm/vc4: Add an API for creating GPU shaders in GEM BOs.") Cc: stable@vger.kernel.org Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/dri-devel/20260720085554.B0AF01F000E9@smtp.kernel.org/ Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Link: https://patch.msgid.link/20260721011558.1672477-1-lilinmao@kylinos.cn Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-07-21drm/tests/gpu_buddy: add a new test case for buffer clearance during resumeArunpravin Paneer Selvam
Add a new unit test case for buffer clearance issue during resume. Using a non-power-of-two mm size, allocate alternating blocks of 4KiB in an even sequence and free them as cleared. All alternate blocks should be marked as dirty and the split blocks should be merged back to their original size when the blocks clear reset function is called. Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260721114236.507578-1-Arunpravin.PaneerSelvam@amd.com
2026-07-21drm/xe/migrate: Revamp PAT index selection for migrate PTEsSanjay Yadav
Improve PAT index selection logic in xe_migrate.c to avoid unnecessary coherency overhead when host-side memory is uncached. Previously, we defaulted to XE_CACHE_WB, which enforces 2-way coherency and may trigger cacheline pulls from CPU even when host-side memory is never dirty. This change introduces xe_migrate_pat_index() to choose the appropriate PAT index based on the actual TTM caching mode of the buffer object being mapped. For iGPUs with WC host mappings, we now prefer XE_CACHE_NONE to skip coherency snoops. For compressed PTEs on newer platforms, we select XE_CACHE_NONE_COMPRESSION. This avoids unnecessary cache traffic for uncached host mappings. v6: (sashiko) - Only apply the BO's host-side caching for system-memory PTEs. v5: (Matt A) - Simplify emit_pte() to derive caching from res->bo directly, removing the separate bo parameter - Leave changes in __xe_migrate_update_pgtables() and build_pt_update_batch_sram() - Fix comment about page-walker coherency in xe_migrate_pat_index() v4: - Keep xe_migrate_prepare_vm() on XE_CACHE_WB since page tables require page-walker coherency. - Pass BO into emit_pte() and select PAT attributes from the BO's TTM caching mode. Assisted-by: Github-Copilot:claude-opus-4.8 Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710083004.1546599-2-sanjay.kumar.yadav@intel.com
2026-07-21drm/i915/bw: Update bw calculation to account for 16 channelsUma Shankar
Wa_16030862157: Update Bandwidth Calculation to account for 16channel memory config. v2: Logical separation of changes (Suraj, Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 68859 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-3-uma.shankar@intel.com
2026-07-21drm/i915/dram: Interpret 0xF populated-channel count as 16Uma Shankar
Wa_16030862157: Interpret 0xF populated-channel count as 16 The register MEM_SS_INFO_GLOBAL [Number of populated channels] field definition is updated with an encoding for 16 channels. For 16-channel configuration, program 1111b. A programmed value of 1111b must be interpreted as 16 channels for memory bandwidth calculations. The MEM_SS_INFO_GLOBAL populated-channel field is only 4 bits and cannot encode 16, so on Xe3p the BIOS programs the saturated field value (0xf) to indicate the fully-populated 16-channel config (4 memory controllers x 4 channels). Interpret it as 16 and let the bandwidth math handle the larger channel count. v2: Limit the WA only till NVL (Suraj) Logical separation of WA (Vinod) WA: 16030862157, 16030875223 Bspec: 69131, 79482 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patch.msgid.link/20260715143243.4141208-2-uma.shankar@intel.com
2026-07-21drm/gpusvm: Zero HMM PFNs before scanning rangesStanislav Kinsburskii
drm_gpusvm_scan_mm() asks HMM to report the current CPU page-table state without faulting missing entries by leaving default_flags set to zero. The HMM PFN array is still caller-owned input/output state, and the framework may preserve input bits while filling entries. It is not safe for the caller to hand HMM an uninitialized array and then treat entries without HMM_PFN_VALID as an authoritative unpopulated result. Use kvcalloc() for the temporary PFN array so entries that are not reported as valid start from the documented zero state. This prevents random stack or heap contents from being interpreted as HMM PFN flags or PFN values during the scan. Fixes: f1d08a586482 ("drm/gpusvm: Introduce a function to scan the current migration state") Cc: stable@vger.kernel.org Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/178406967042.1113483.2116704310277917086.stgit@skinsburskii
2026-07-21drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evictMatthew Brost
If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path. Fixes: 99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory") Cc: stable@vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260714170025.3487974-1-matthew.brost@intel.com
2026-07-21rust: device: make lifetime on `Core` and `CoreInternal` invariantGary Guo
Currently the lifetime on `Core` and `CoreInternal` is covariant. This means that they can be coerced into shorter living lifetimes. On `probe` function, signature has `&'bound Device<Core<'a>>`; the type's wellformness would imply `'a: 'bound` and thus the type can be coerced `&'bound Device<Core<'bound>>`, defeating the purpose of having the lifetime bound to prevent users of the `Core` type to escape the function. Fix this by making the lifetime invariant, so the coercion is impossible. The lifetime here only needs to be "branded" so it does not coerce or unify with other lifetimes, so we do not need to ensure `'bound: 'a`. This requires modifying `nova-core` which relies on this implied bound due to pre-2024 capture rule. The "use" bound can be removed if built with edition 2024. Fixes: 24799831d631 ("rust: device: make Core and CoreInternal lifetime-parameterized") Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260713201455.640151-1-gary@kernel.org [ Fixup the debugfs sample to use an explicit lifetime instead of Core<'_>. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-20drm/panel: panel-edp: Adjust T8 timing for AUO B116XAK01.6 and B140XTK02.4Dio Zhang
Screen garbage or flickering can be observed during mode changes (such as VT switches) on systems using the AUO B116XAK01.6 and B140XTK02.4 panels. This occurs because the backlight is enabled before the video signal stabilizes. Waveform measurements show that the panel signal takes around 140ms to stabilize after a mode change, meaning the previous 50ms T8 timing was insufficient. To resolve this issue, adjust the eDP panel delay entry from delay_200_500_e50 to delay_200_500_e200 (increasing T8 from 50ms to 200ms). This matches the updated panel specifications from AUO, which now formally define T8 as 200ms to mask any display abnormalities during mode changes. Signed-off-by: Dio Zhang <dioyc_zhang@compal.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260720025358.2781136-1-dioyc_zhang@compal.corp-partner.google.com
2026-07-20drm/panfrost: Remove unused scheduled_jobs listMaíra Canal
The scheduled_jobs list head was introduced in commit f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") but never used. Remove the dead field and its initialization. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://patch.msgid.link/20260710121423.2820472-2-mcanal@igalia.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-07-20drm/xe/madvise: Skip invalidation for purgeable state updatesArvind Yadav
Purgeable state updates only change VMA/BO metadata. They do not zap PTEs when switching between DONTNEED and WILLNEED. PTEs are zapped later if the BO is actually purged. xe_vm_invalidate_madvise_range() waits on the VM dma-resv before checking vma->skip_invalidation. Since purgeable madvise marks all affected VMAs to skip invalidation, this wait is unnecessary and can stall on unrelated in-flight work. Skip the invalidate path entirely for purgeable state updates. v2: - Replace inline 'args->type != DRM_XE_VMA_ATTR_PURGEABLE_STATE' check with a small helper madvise_range_needs_invalidation(). (Himal) Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patch.msgid.link/20260526135447.2973029-1-arvind.yadav@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Cc: <stable@vger.kernel.org> # v6.18+ (cherry picked from commit 134377098b9c14abd31c3bcac00c9653f0f0c4c3) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
2026-07-20drm/hyperv: Move MODULE_DEVICE_TABLE to the device_id arraysUwe Kleine-König (The Capable Hub)
It matches the usual coding style to have the MODULE_DEVICE_TABLE macro directly after the respective arrays. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/7f9d4a239c76b6bb384048ea5591a21ed87d9b0e.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/hyperv: Explicitly set subvendor and subdevice for pci match arrayUwe Kleine-König (The Capable Hub)
.subvendor and .subdevice were set to 0 implicitly, so only devices with these two values set to 0 in hardware can probe automatically. Make this requirement explicit. While touching this array item, also make use of the pci macro designed for that case. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/019450ffb519d02821364afca32b9f48bcd8d2b6.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/hyperv: Unregister pci driver in error path before module unloadUwe Kleine-König (The Capable Hub)
The pci driver must not kept registered if the module is unloaded after vmbus_driver_register() fails. So check the return value of vmbus_driver_register() and unregister the pci driver on failure. Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/4b7dbf00ce4ff664b7d5dd74b2f39d8d87c1ade9.1782925276.git.u.kleine-koenig@baylibre.com
2026-07-20drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VMIcenowy Zheng
The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [<ffffffff01e989d4>] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [<ffffffff01ed3a40>] pvr_vm_unmap+0x34/0x68 [powervr] [<ffffffff01ec69da>] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [<ffffffff8080ce0a>] drm_ioctl_kernel+0x8e/0xdc [<ffffffff8080d016>] drm_ioctl+0x1be/0x3e0 [<ffffffff802bec3e>] __riscv_sys_ioctl+0xba/0xc4 [<ffffffff80d858b2>] do_trap_ecall_u+0x23e/0x3f4 [<ffffffff80d92288>] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*(). Cc: stable@vger.kernel.org Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code") Fixes: 4bc736f890ce ("drm/imagination: vm: make use of GPUVM's drm_exec helper") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260714073641.1935075-1-zhengxingda@iscas.ac.cn Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20drm/imagination: Use struct_size_t()Matt Coster
The helpers for dealing with flexible structures exist, so let's use them. Signed-off-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20250709-flex-array-check-v1-2-8adeb0bf0cde@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20drm/imagination: Add and use FLEX_ARRAY_CHECK()Matt Coster
It makes little to no sense to use SIZE_CHECK() on flexible structures, so let's validate something that actually matters instead. Signed-off-by: Matt Coster <matt.coster@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20250709-flex-array-check-v1-1-8adeb0bf0cde@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-20drm/panel: sofef00: Fix DSI transfer errors on backlight updateCédric Bellegarde
Backlight updates via bl_update_status() could be triggered before the panel was fully initialized, resulting in failed DCS commands during the atomic commit sequence. Guard bl_update_status() with a prepared flag to skip backlight updates when the panel is not yet ready. [11816.846734] disp_cc_mdss_byte0_clk status stuck at 'on' [11816.846752] WARNING: CPU: 4 PID: 26399 at drivers/clk/qcom/clk-branch.c:88 clk_branch_toggle+0x128/0x178 [11816.861715] Modules linked in: rfcomm rmnet algif_hash algif_skcipher q6asm_dai q6voice_dai q6routing q6afe_dai q6voice q6adm q6cvp q6afe q6asm q6mvm q6 cvs q6voice_common snd_q6dsp_common q6core bnep gpio_wcd934x snd_soc_wcd934x snd_soc_wcd_mbhc soundwire_qcom snd_soc_wcd_classh venus_enc venus_dec imx371 wcd9 34x regmap_slimbus imx376 lc898217xc videobuf2_dma_contig fastrpc v4l2_cci qrtr_smd rpmsg_ctrl hci_uart btqca btbcm bluetooth ecdh_generic ecc pwrseq_core snd_ soc_max98927 qcom_camss ath10k_snoc videobuf2_dma_sg snd_soc_sdm845 videobuf2_memops venus_core ath10k_core qcom_smbx leds_qcom_flash snd_soc_rt5663 leds_qcom_ lpg ath v4l2_mem2mem snd_soc_qcom_sdw videobuf2_v4l2 v4l2_fwnode videobuf2_common v4l2_async snd_soc_qcom_common bq27xxx_battery_i2c qcom_pbs bq27xxx_battery l ed_class_multicolor mac80211 snd_soc_rl6231 rtc_pm8xxx libarc4 soundwire_bus videodev qcom_stats qcom_spmi_rradc reset_qcom_pdc i2c_qcom_cci cfg80211 camcc_sdm 845 rfkill mc qcom_rng ipa qcom_q6v5_mss slim_qcom_ngd_ctrl qcom_wdt icc_bwmon qrtr [11816.861812] qcom_q6v5_pas qcom_pil_info qcom_q6v5 qcom_sysmon qcom_common qcom_glink_smem joydev zram zsmalloc uhid uinput nft_reject_inet nft_reject n f_reject_ipv6 nf_reject_ipv4 nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables fuse nfnetlink ipv6 qcom_spmi_haptics rmi_i2c rmi_core [11816.978965] CPU: 4 UID: 0 PID: 26399 Comm: (sd-bright) Tainted: G W 6.16.7-sdm845 #1000-postmarketos-qcom-sdm845 PREEMPT [11816.991580] Tainted: [W]=WARN [11816.994637] Hardware name: OnePlus 6 (DT) [11816.998735] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [11817.005844] pc : clk_branch_toggle+0x128/0x178 [11817.010384] lr : clk_branch_toggle+0x124/0x178 [11817.014956] sp : ffff8000991f3970 [11817.018358] x29: ffff8000991f3980 x28: ffff0000dad38000 x27: 0000000000000000 [11817.025634] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [11817.032887] x23: 0000000000000000 x22: ffffa63e2af42178 x21: ffffa63e2b56e128 [11817.040169] x20: ffffa63e29da5a90 x19: 0000000000000000 x18: 0000000000000003 [11817.047451] x17: 0000000000000000 x16: 000000000000000c x15: 0000000000000003 [11817.054701] x14: ffffa63e2b2f6a10 x13: 0000000000000003 x12: 0000000000000003 [11817.061982] x11: 00000000ffffefff x10: c0000000ffffefff x9 : e43cc05c4996c100 [11817.069260] x8 : e43cc05c4996c100 x7 : 7461206b63757473 x6 : 0000000000000027 [11817.076511] x5 : ffffa63e2b8726d3 x4 : ffffa63e2ae146c4 x3 : 0000000000000000 [11817.083792] x2 : 0000000000000000 x1 : ffff8000991f3710 x0 : 00000000fffffff0 [11817.091042] Call trace: [11817.093572] clk_branch_toggle+0x128/0x178 (P) [11817.098112] clk_branch2_disable+0x28/0x40 [11817.102308] clk_core_disable+0x64/0x1b8 [11817.106358] clk_core_disable_lock+0x90/0x120 [11817.110810] clk_disable+0x2c/0x40 [11817.114298] dsi_link_clk_disable_6g+0x78/0x98 [11817.118871] msm_dsi_host_xfer_restore+0xf0/0x120 [11817.123667] msm_dsi_manager_cmd_xfer+0xfc/0x178 [11817.128411] dsi_host_transfer+0x48/0x110 [11817.132509] mipi_dsi_dcs_set_display_brightness_large+0x8c/0xd0 [11817.138651] sofef00_panel_bl_update_status+0x3c/0x60 [11817.143802] backlight_device_set_brightness+0x88/0x128 [11817.149124] brightness_store+0x64/0xa8 [11817.153082] dev_attr_store+0x24/0x40 [11817.156835] sysfs_kf_write+0x8c/0xb8 [11817.160591] kernfs_fop_write_iter+0xe4/0x190 [11817.165073] do_iter_readv_writev+0x168/0x1c8 [11817.169515] vfs_writev+0x16c/0x378 [11817.173122] do_writev+0x84/0x130 [11817.176523] __arm64_sys_writev+0x2c/0x40 [11817.180618] invoke_syscall+0x48/0x100 [11817.184460] el0_svc_common+0x88/0xe8 [11817.188217] do_el0_svc+0x28/0x40 [11817.191621] el0_svc+0x38/0x88 [11817.194766] el0t_64_sync_handler+0x78/0x108 [11817.199161] el0t_64_sync+0x198/0x1a0 Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260706051825.78752-1-cedric.bellegarde@adishatz.org
2026-07-20drm/panel: Add Novatek NT36536 panel driverPengyu Luo
Add a driver for panels using the Novatek NT36536 Display Driver IC, including support for the CSOT PP8807HB1-1, a dual-link 10-bit panel found in LENOVO Legion Y700 Gen4. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260709142846.12463-3-mitltlatltl@gmail.com
2026-07-20drm/panel: find_panel_by_fwnode() return a counted referenceAlbert Esteve
find_panel_by_fwnode() is the fwnode-based counterpart to of_drm_find_panel(), used internally by drm_panel_add_follower(). Like of_drm_find_panel(), it returned an unrefcounted pointer, leaving a window where the panel could be freed between the lookup and first use. drm_panel_add_follower() worked around the missing panel kref by calling get_device() on the panel's underlying struct device. However, get_device() only prevents the device kobject from being freed. It does not prevent the panel's kzalloc()'d container memory from being released when the kref reaches zero. Apply the same fix: call drm_panel_get() under panel_lock before returning. Since find_panel_by_fwnode() now transfers a counted reference to drm_panel_add_follower(), drm_panel_remove_follower() must balance it with a matching drm_panel_put(). Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-4-023900c32e01@redhat.com
2026-07-20drm/panel: of_drm_find_panel() return a counted referenceAlbert Esteve
Callers of of_drm_find_panel() and drm_of_find_panel_or_bridge() receive a pointer with no reference held, creating a window where the panel device can be unregistered and freed between the lookup and first use (e.g., drm_panel_prepare()). Fix the lookup function by acquiring a reference with drm_panel_get() before returning, under panel_lock. Callers are now responsible for calling drm_panel_put() when they no longer need the pointer. For bridge drivers that immediately wrap the panel in a panel_bridge (which acquires its own reference), release the lookup reference right after the bridge creation call. For analogix-anx6345, which stores the panel for direct use, release the reference in the i2c remove path. For platform drivers using analogix_dp_core with a component lifecycle (exynos_dp, rockchip analogix_dp), release the lookup reference in the platform remove() function. The panel_bridge created during bind() holds a separate reference that devm cleanup releases after remove() returns. Also fix devm_drm_of_get_bridge() and drmm_of_get_bridge() in bridge/panel.c itself, update a second batch of drivers calling of_drm_find_panel() or drm_of_find_panel_or_bridge() to release the lookup reference after wrapping the panel in a bridge, and handle the cases where a panel is found but cannot be used, dropping the reference immediately in those paths. Assisted-by: Claude:claude-opus-4-6 Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-3-023900c32e01@redhat.com
2026-07-20drm/bridge/panel: hold a reference to the wrapped panelAlbert Esteve
drm_panel_bridge_add_typed() stores a pointer to the drm_panel it wraps, but never acquires a reference to it. If the panel device goes away while a panel_bridge still exists, the dangling pointer can be dereferenced through panel_bridge->panel. Acquire a reference in drm_panel_bridge_add_typed() with drm_panel_get() and release it in each teardown path. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-2-023900c32e01@redhat.com
2026-07-20drm/panel: have drm_panel_add/remove manage a list referenceAlbert Esteve
The global panel_list holds raw pointers to drm_panel objects. Nothing prevents a panel from being freed while it is still linked in the list: if a driver's probe calls drm_panel_add() and then fails at a later step, panel->list remains in panel_list. Any subsequent call to of_drm_find_panel() that iterates the list will dereference freed memory. Have drm_panel_add() acquire a reference via drm_panel_get() before inserting the panel into the list, and have drm_panel_remove() drop it via drm_panel_put() after removing the panel from the list. The global registry now holds a counted reference for as long as the panel is listed, ensuring the object outlives any concurrent lookup. Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260717-drm_refcount_wiring-v3-1-023900c32e01@redhat.com
2026-07-20drm/i915/dp_tunnel: Add UHBR tunneling supportImre Deak
Add support for UHBR link rates on Thunderbolt tunneled links. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-7-imre.deak@intel.com
2026-07-20drm/i915/dp: Disable UHBR link configs with 1/2 lanesImre Deak
Disable 1 and 2 lane link configurations on UHBR tunneled links, according to DP Standard v2.1b "3.5.2.16.3 128b/132b DPRX Lane Count Conversion Failure Indication and Corrective Action". A tunnel can indicate if it's not affected by this limitation, check for that and skip disabling the unsupported lanes for a well-behaving tunnel. The Standard in the same section also describes a workaround for 2 lanes which requires assisstance from the sink, where the sink indicates at the end of the link training sequence if the link training must be retried. This mechanism also requires quirking out some sinks - based on the sink's DPCD OUI and EDID identifications - which doesn't implement this link training feedback indication properly. This patch leaves the implementation of this workaround for a follow-up, but prepares for it already by detecting the supported number of lane counts at a place where both DPCD OUI and EDID is available for the quirk detection. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-6-imre.deak@intel.com
2026-07-20drm/i915/dp: Remove UHBR dependency from SST fallback kunit testImre Deak
After fallback between UHBR and non-UHBR link rates got enabled in a previous change, there is no need to test fallback sequences for UHBR and non-UHBR rates separately. Make the test simply start from the maximum (UHBR) rate. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-5-imre.deak@intel.com
2026-07-20drm/i915/dp: Enable SST fallback between UHBR and non-UHBR ratesImre Deak
Enable link training fallback between UHBR and non-UHBR link rates on DP SST links. This was disabled so far to preserve the fallback behavior. There isn't a known issue related to such a fallback and DP MST has been using this for a while already. Also, enabling UHBR rates over Thunderbolt tunnels in a follow-up change, which at least on some links supports only 4 lanes and not 1 or 2 lanes on UHBR, makes a UHBR->non-UHBR fallback scenario more likely. At the same time align the corresponding link training fallback kunit test, allowing a UHBR <-> non-UHBR fallback there as well. Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.comd> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-4-imre.deak@intel.com
2026-07-20drm/i915/dp: End link configuration loops properlyImre Deak
Call intel_dp_link_caps_iter_end() after the link configuration loops. At the moment this call only clears the iteration object, so the lack of call didn't cause an actual issue. Cc: Luca Coelho <luciano.coelho@intel.com> Fixes: 7266df62ed0a7 ("drm/i915/dp: Iterate configurations via link_caps for SST non-DSC") Fixes: 4f104fc10a461 ("drm/i915/dp: Iterate configurations via link_caps for SST DSC") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-3-imre.deak@intel.com
2026-07-20drm/dp_tunnel: Add UHBR tunneling supportImre Deak
Add the DPCD registers and detection required to support UHBR link rates over Thunderbolt tunnels. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260714152700.555527-2-imre.deak@intel.com
2026-07-20drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD ↵Suraj Kandpal
backlight Turns out some panels allow only AUX based backlight by just setting the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and not setting the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP. If we make DP_EDP_BACKLIGHT_AUX_ENABLE_CAP a necessity for AUX based DPCD backlight these panels loose the ability to manipulate backlight via AUX, especially ones with no PWM controller. Remove this check from function so that panels who do not advertise DP_EDP_BACKLIGHT_AUX_ENABLE_CAP but advertise DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP are able to manipulate backlight again. Fixes: ed8be780bdbc ("drm/i915/backlight: Fix VESA backlight possible check condition") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16507 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260716030959.436430-1-suraj.kandpal@intel.com (cherry picked from commit 7d594b24c915afb4b0c5fb8875403253daef5b24) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-07-20drm/i915/backlight: Remove DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check for DPCD ↵Suraj Kandpal
backlight Turns out some panels allow only AUX based backlight by just setting the DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP and not setting the DP_EDP_BACKLIGHT_AUX_ENABLE_CAP. If we make DP_EDP_BACKLIGHT_AUX_ENABLE_CAP a necessity for AUX based DPCD backlight these panels loose the ability to manipulate backlight via AUX, especially ones with no PWM controller. Remove this check from function so that panels who do not advertise DP_EDP_BACKLIGHT_AUX_ENABLE_CAP but advertise DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP are able to manipulate backlight again. Fixes: ed8be780bdbc ("drm/i915/backlight: Fix VESA backlight possible check condition") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16507 Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260716030959.436430-1-suraj.kandpal@intel.com
2026-07-20drm/xe/xe_ras: Add support to query device memory errorsRiana Tauro
Add initial support to query uncorrectable device memory errors from system controller. The recovery action for memory errors depends on the error category. Firmware will set only one error category per response. Double bit ECC (Error Correcting Code) errors will be handled using Page offlining in a later patch. Poison and data parity errors are only logged. Rest of the errors require SBR (Secondary Bus Reset) to recover. Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260717141650.2487761-8-riana.tauro@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-20drm/xe/xe_ras: Handle uncorrectable SoC Internal errorsRiana Tauro
Some critical errors such as CSC firmware and Punit are reported under SoC internal errors and require special handling. CSC errors are classified into hardware errors and firmware errors. Hardware errors can be recovered using a SBR (Secondary Bus Reset) whereas firmware errors are critical and require a firmware flash. On such errors, device is wedged and runtime survivability mode will be enabled to notify userspace that a firmware flash is required. PUNIT uncorrectable errors can only be recovered through a cold reset. Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260717141650.2487761-7-riana.tauro@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-20drm/xe/xe_survivability: Decouple survivability info from boot survivabilityRiana Tauro
On CSC runtime firmware errors that requires firmware flash through SPI, PCODE sets the FDO mode bit in the Capability register. Currently the survivability_info group is created only for boot survivability. Create survivability_info group even for runtime survivability to allow userspace to check FDO mode sysfs. Reviewed-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Link: https://patch.msgid.link/20260717141650.2487761-6-riana.tauro@intel.com Signed-off-by: Riana Tauro <riana.tauro@intel.com>
2026-07-20drm/xe/i2c: use device_create_managed_software_node()Bartosz Golaszewski
This driver intentionally uses the fine-grained approach to creating platform devices. It assigns a software node as the primary firmware node of the device it creates. Ahead of improving the reference counting of platform device software nodes, switch to using device_create_managed_software_node(). This way, we create a dynamic software node whose life-time is tied to the device to which it's assigned. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-swnode-remove-on-dev-unreg-v8-3-5c2b8cc38c28@oss.qualcomm.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-07-18drm/msm/a6xx: Add Adreno 722 supportPuranam V G Tejaswi
Add support for Adreno A722, a member of the GEN1 A7xx family. It is derived from A730 and shares the same IP-level configurations: HWCG registers, protected registers, GBIF CX registers and gmu_cgc_mode. Major differences include lower cache/core counts, 1MB GMEM, no Concurrent Binning & LPAC support. Some of the peripheral blocks like RSCC are from A740 that resulted in updates to RSC layout. Add a new entry to the catalog to describe the usual configuration and few additional fixup mainly due to missing CB/LPAC features and updated RSC layout. Signed-off-by: Puranam V G Tejaswi <puranam.tejaswi@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/740959/ Message-ID: <20260718-eliza-gpu-v2-3-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-15 12:52:42 +0000