kernel/drivers/gpu/drm/msm/msm_gem_vma.c, branch linux-rolling-stable

drm/msm: msm_gem_vma.c: fix all kernel-doc warnings

2025-12-24T09:24:19Z

Correct or add kernel-doc comments to eliminate all warnings: Warning: ../drivers/gpu/drm/msm/msm_gem_vma.c:96 expecting prototype for struct msm_vma_op. Prototype was for struct msm_vm_op instead Signed-off-by: Randy Dunlap Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/695679/ Link: https://lore.kernel.org/r/20251219184638.1813181-18-rdunlap@infradead.org Signed-off-by: Dmitry Baryshkov

drm/msm: Add NULL check in vm_op_enqueue()

2025-11-15T17:10:44Z

vm_op_enqueue() allocates an msm_vm_op struct with kmalloc, but the return value is not checked for NULL value which can be returned by kmalloc under low-memory conditions. This can result in NULL pointer dereference when the pointer is dereferenced. Add NULL check after the allocation and propagate -ENOMEM back to the caller in case of a failure. Signed-off-by: Gopi Krishna Menon Patchwork: https://patchwork.freedesktop.org/patch/678416/ Signed-off-by: Rob Clark

Merge remote-tracking branch 'drm/drm-next' into msm-next-robclark

2025-11-01T12:47:30Z

Back-merge drm-next to get caught up. Signed-off-by: Rob Clark

drm/msm: Ensure vm is created in VM_BIND ioctl

2025-10-25T17:01:11Z

Since the vm is lazily created, to allow userspace to opt-in to a VM_BIND context, we can't assume it is already created. Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/682939/ Message-ID: <20251022222039.9937-1-robin.clark@oss.qualcomm.com>

drm/msm: Reject MAP_NULL op if no PRR

2025-10-25T17:01:03Z

We need PRR support in order to implement MAP_NULL. Userspace shouldn't be trying to use this if it is unsupported. Reported-by: Valentine Burley Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37935#note_3153730 Signed-off-by: Rob Clark Tested-by: Valentine Burley Patchwork: https://patchwork.freedesktop.org/patch/682941/ Message-ID: <20251022222051.10030-1-robin.clark@oss.qualcomm.com>

Merge tag 'drm-msm-next-2025-09-12' of https://gitlab.freedesktop.org/drm/msm into drm-next

2025-09-16T00:21:38Z

Changes for v6.18 GPU and Core: - in DT bindings describe clocks per GPU type - GMU bandwidth voting for x1-85 - a663 speedbins - a623 speedbins - cleanup some remaining no-iommu leftovers after VM_BIND conversion - fix GEM obj 32b size truncation - add missing VM_BIND param validation - various fixes - IFPC for x1-85 and a750 - register xml and gen_header.py sync from mesa Display: - add missing bindings for display on SC8180X - added DisplayPort MST bindings - conversion from round_rate() to determine_rate() - DSI PHY fixes, correcting programming glitches - misc small fixes Signed-off-by: Dave Airlie From: Rob Clark Link: https://lore.kernel.org/r/CACSVV01FgXN+fD6U1Hi6Tj4WCf=V-+NO8BXi+80iS4qOZwpaGg@mail.gmail.com

Merge tag 'v6.17-rc6' into drm-next

2025-09-15T07:51:07Z

This is a backmerge of Linux 6.17-rc6, needed for msm, also requested by misc. Signed-off-by: Dave Airlie

drm/msm: Fix missing VM_BIND offset/range validation

2025-09-06T15:58:11Z

We need to reject the MAP op if offset+range is larger than the BO size. Reported-by: Connor Abbott Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Tested-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/669781/

drm/msm: Fix obj leak in VM_BIND error path

2025-09-06T15:58:11Z

If we fail a handle-lookup part way thru, we need to drop the already obtained obj references. Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl") Signed-off-by: Rob Clark Tested-by: Connor Abbott Patchwork: https://patchwork.freedesktop.org/patch/669784/

drm/msm: fix msm_gem_vma_new() allocations for managed GPUVMs

2025-08-23T14:20:18Z

Since commit 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") MSM driver fails to init, failing with "[drm:msm_gpu_init] *ERROR* could not allocate memptrs: -22" errors. The mentioned commit reworked the function, but didn't take into account that op_map is initialized at the top of the function, while ranges might change if GPUVM is managed by the kernel. Move op_mode initialization after finalizing all addresses and right before the drm_gpuva_init_from_op() call. Reported-by: Danct12 Fixes: 3309323241fb ("drm/gpuvm: Kill drm_gpuva_init()") Suggested-by: Rob Clark Reviewed-by: Rob Clark Acked-by: Rob Clark Link: https://lore.kernel.org/r/20250823-msm-fix-gpuvm-init-v1-1-e199cd5b1983@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov