linux-stable.git/drivers, branch v6.18.4

Revert "gpio: swnode: don't use the swnode's name as the key for GPIO lookup"

2026-01-08T09:17:21+00:00

This reverts commit e5d527be7e6984882306b49c067f1fec18920735.

This software node change doesn't actually fix any current issues
with the kernel, it is an improvement to the lookup process rather
than fixing a live bug. It also causes a couple of regressions with
shipping laptops, which relied on the label based lookup.

There is a fix for the regressions in mainline, the first 5 patches
of [1]. However, those patches are fairly substantial changes and
given the patch causing the regression doesn't actually fix a bug
it seems better to just revert it in stable.

CC: stable@vger.kernel.org # 6.18
Link: https://lore.kernel.org/linux-sound/20251120-reset-gpios-swnodes-v7-0-a100493a0f4b@linaro.org/ [1]
Closes: https://github.com/thesofproject/linux/issues/5599
Closes: https://github.com/thesofproject/linux/issues/5603
Acked-by: Bartosz Golaszewski 
Signed-off-by: Charles Keepax 
Signed-off-by: Greg Kroah-Hartman

vfio/pci: Disable qword access to the PCI ROM bar

2026-01-08T09:17:21+00:00

[ Upstream commit dc85a46928c41423ad89869baf05a589e2975575 ]

Commit 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio
pci") enables qword access to the PCI bar resources. However certain
devices (e.g. Intel X710) are observed with problem upon qword accesses
to the rom bar, e.g. triggering PCI aer errors.

This is triggered by Qemu which caches the rom content by simply does a
pread() of the remaining size until it gets the full contents. The other
bars would only perform operations at the same access width as their
guest drivers.

Instead of trying to identify all broken devices, universally disable
qword access to the rom bar i.e. going back to the old way which worked
reliably for years.

Reported-by: Farrah Chen 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220740
Fixes: 2b938e3db335 ("vfio/pci: Enable iowrite64 and ioread64 for vfio pci")
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Tian 
Tested-by: Farrah Chen 
Link: https://lore.kernel.org/r/20251218081650.555015-2-kevin.tian@intel.com
Signed-off-by: Alex Williamson 
Signed-off-by: Greg Kroah-Hartman

powercap: intel_rapl: Add support for Nova Lake processors

2026-01-08T09:17:21+00:00

commit 58075aec92a8141fd7f42e1c36d1bc54552c015e upstream.

Add RAPL support for Intel Nova Lake and Nova Lake L processors using
the core defaults configuration.

Signed-off-by: Kaushlendra Kumar 
[ rjw: Subject and changelog edits, rebase ]
Link: https://patch.msgid.link/20251028101814.3482508-1-kaushlendra.kumar@intel.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

powercap: intel_rapl: Add support for Wildcat Lake platform

2026-01-08T09:17:21+00:00

commit 39f421f2e301f995c17c35b783e2863155b3f647 upstream.

Add Wildcat Lake to the list of supported processors for RAPL.

Signed-off-by: Srinivas Pandruvada 
Link: https://patch.msgid.link/20251023174532.1882008-1-srinivas.pandruvada@linux.intel.com
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

drm/imagination: Disallow exporting of PM/FW protected objects

2026-01-08T09:17:20+00:00

commit 6b991ad8dc3abfe5720fc2e9ee96be63ae43e362 upstream.

These objects are meant to be used by the GPU firmware or by the PM unit
within the GPU, in which case they may contain physical addresses.

This adds a layer of protection against exposing potentially exploitable
information outside of the driver.

Fixes: ff5f643de0bf ("drm/imagination: Add GEM and VM related code")
Signed-off-by: Alessio Belle 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251208-no-export-pm-fw-obj-v1-1-83ab12c61693@imgtec.com
Signed-off-by: Matt Coster 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fb

2026-01-08T09:17:20+00:00

commit 560271e10b2c86e95ea35afa9e79822e4847f07a upstream.

Since we recently started warning about uses of this function after the
atomic check phase completes, we've started getting warnings about this in
nouveau. It appears a misplaced drm_atomic_get_crtc_state() call has been
hiding in our .prepare_fb callback for a while.

So, fix this by adding a new nv50_head_atom_get_new() function and use that
in our .prepare_fb callback instead.

Signed-off-by: Lyude Paul 
Reviewed-by: Dave Airlie 
Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files")
Cc:  # v4.18+
Link: https://patch.msgid.link/20251211190256.396742-1-lyude@redhat.com
Signed-off-by: Greg Kroah-Hartman

drm/pagemap, drm/xe: Ensure that the devmem allocation is idle before use

2026-01-08T09:17:20+00:00

commit 754c23238438600e9236719f7e67aff2c4d02093 upstream.

In situations where no system memory is migrated to devmem, and in
upcoming patches where another GPU is performing the migration to
the newly allocated devmem buffer, there is nothing to ensure any
ongoing clear to the devmem allocation or async eviction from the
devmem allocation is complete.

Address that by passing a struct dma_fence down to the copy
functions, and ensure it is waited for before migration is marked
complete.

v3:
- New patch.
v4:
- Update the logic used for determining when to wait for the
  pre_migrate_fence.
- Update the logic used for determining when to warn for the
  pre_migrate_fence since the scheduler fences apparently
  can signal out-of-order.
v5:
- Fix a UAF (CI)
- Remove references to source P2P migration (Himal)
- Put the pre_migrate_fence after migration.
v6:
- Pipeline the pre_migrate_fence dependency (Matt Brost)

Fixes: c5b3eb5a906c ("drm/xe: Add GPUSVM device memory copy vfunc functions")
Cc: Matthew Brost 
Cc:  # v6.15+
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Brost 
Acked-by: Maarten Lankhorst  # For merging through drm-xe.
Link: https://patch.msgid.link/20251219113320.183860-4-thomas.hellstrom@linux.intel.com
(cherry picked from commit 16b5ad31952476fb925c401897fc171cd37f536b)
Signed-off-by: Thomas Hellström 
Signed-off-by: Greg Kroah-Hartman

drm/xe/svm: Fix a debug printout

2026-01-08T09:17:20+00:00

commit d2d7f5636f0d752a1e0e7eadbbc1839c29177bba upstream.

Avoid spamming the log with drm_info(). Use drm_dbg() instead.

Fixes: cc795e041034 ("drm/xe/svm: Make xe_svm_range_needs_migrate_to_vram() public")
Cc: Matthew Brost 
Cc: Himal Prasad Ghimiray 
Cc:  # v6.17+
Signed-off-by: Thomas Hellström 
Reviewed-by: Himal Prasad Ghimiray 
Link: https://patch.msgid.link/20251219113320.183860-2-thomas.hellstrom@linux.intel.com
(cherry picked from commit 72aee5f70ba47b939345a0d3414b51b0639c5b88)
Signed-off-by: Thomas Hellström 
Signed-off-by: Greg Kroah-Hartman

drm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer

2026-01-08T09:17:20+00:00

commit 4fe2bd195435e71c117983d87f278112c5ab364c upstream.

Initialize the eb.vma array with values of 0 when the eb structure is
first set up. In particular, this sets the eb->vma[i].vma pointers to
NULL, simplifying cleanup and getting rid of the bug described below.

During the execution of eb_lookup_vmas(), the eb->vma array is
successively filled up with struct eb_vma objects. This process includes
calling eb_add_vma(), which might fail; however, even in the event of
failure, eb->vma[i].vma is set for the currently processed buffer.

If eb_add_vma() fails, eb_lookup_vmas() returns with an error, which
prompts a call to eb_release_vmas() to clean up the mess. Since
eb_lookup_vmas() might fail during processing any (possibly not first)
buffer, eb_release_vmas() checks whether a buffer's vma is NULL to know
at what point did the lookup function fail.

In eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper
function eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is
set to NULL in case i915_gem_object_userptr_submit_init() fails; the
current one needs to be cleaned up by eb_release_vmas() at this point,
so the next one is set. If eb_add_vma() fails, neither the current nor
the next vma is set to NULL, which is a source of a NULL deref bug
described in the issue linked in the Closes tag.

When entering eb_lookup_vmas(), the vma pointers are set to the slab
poison value, instead of NULL. This doesn't matter for the actual
lookup, since it gets overwritten anyway, however the eb_release_vmas()
function only recognizes NULL as the stopping value, hence the pointers
are being set to NULL as they go in case of intermediate failure. This
patch changes the approach to filling them all with NULL at the start
instead, rather than handling that manually during failure.

Reported-by: Gangmin Kim 
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15062
Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
Cc: stable@vger.kernel.org # 5.16.x
Signed-off-by: Krzysztof Niemiec 
Reviewed-by: Janusz Krzysztofik 
Reviewed-by: Krzysztof Karas 
Reviewed-by: Andi Shyti 
Signed-off-by: Andi Shyti 
Link: https://lore.kernel.org/r/20251216180900.54294-2-krzysztof.niemiec@intel.com
(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/msm: add PERFCTR_CNTL to ifpc_reglist

2026-01-08T09:17:20+00:00

commit 6c6915bfea212d32844b2b7f22bc1aa3669eabc4 upstream.

Previously this register would become 0 after IFPC took place which
broke all usages of counters.

Fixes: a6a0157cc68e ("drm/msm/a6xx: Enable IFPC on Adreno X1-85")
Cc: stable@vger.kernel.org
Signed-off-by: Anna Maniscalco 
Reviewed-by: Akhil P Oommen 
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/690960/
Message-ID: <20251127-ifpc_counters-v3-1-fac0a126bc88@gmail.com>
Signed-off-by: Rob Clark 
Signed-off-by: Greg Kroah-Hartman