<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/drivers/gpu/drm/i915, branch master</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2026-07-06T14:52:42+00:00</updated>
<entry>
<title>Revert "drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TG"</title>
<updated>2026-07-06T14:52:42+00:00</updated>
<author>
<name>Ankit Nautiyal</name>
<email>ankit.k.nautiyal@intel.com</email>
</author>
<published>2026-06-22T10:17:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3d04d9f390eeaab4d9e1ed4e9737e3d83581e18b'/>
<id>urn:sha1:3d04d9f390eeaab4d9e1ed4e9737e3d83581e18b</id>
<content type='text'>
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.

Fixes: 4f1cab2e4863 ("drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TG")
Signed-off-by: Ankit Nautiyal &lt;ankit.k.nautiyal@intel.com&gt;
Reviewed-by: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Link: https://patch.msgid.link/20260622101736.2389991-1-ankit.k.nautiyal@intel.com
(cherry picked from commit 4dfcc789a144a21aa9be94f19f928aaa9fdc834d)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gem: Do not leak siblings[] on proto context error</title>
<updated>2026-07-06T14:26:13+00:00</updated>
<author>
<name>Joonas Lahtinen</name>
<email>joonas.lahtinen@linux.intel.com</email>
</author>
<published>2026-07-01T07:30:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eed3de2acf6aa5154d49098b026710b646db67ee'/>
<id>urn:sha1:eed3de2acf6aa5154d49098b026710b646db67ee</id>
<content type='text'>
After a successful BALANCE/PARALLEL_SUBMIT extension on context
creation, error during processing of next user extension leaks
the siblings[] array. Fix that.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

Reported-by: Martin Hodo &lt;martin.hodo@intel.com&gt;
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)")
Cc: Faith Ekstrand &lt;faith.ekstrand@collabora.com&gt;
Cc: Simona Vetter &lt;simona.vetter@ffwll.ch&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@igalia.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.15+
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Reviewed-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Signed-off-by: Tvrtko Ursulin &lt;tursulin@ursulin.net&gt;
Link: https://lore.kernel.org/r/20260701073030.44850-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gt: Fix NULL deref on sched_engine alloc failure</title>
<updated>2026-07-06T14:26:06+00:00</updated>
<author>
<name>Joonas Lahtinen</name>
<email>joonas.lahtinen@linux.intel.com</email>
</author>
<published>2026-07-01T11:45:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=82ec992c404c3dc774c5e9f3d4aa858e97187675'/>
<id>urn:sha1:82ec992c404c3dc774c5e9f3d4aa858e97187675</id>
<content type='text'>
Avoid using intel_context_put() before intel_context_init() in
execlists_create_virtual() as the kref_put() inside would lead
to NULL deref on the IOCTL path when sched_engine allocation fails.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

Reported-by: Martin Hodo &lt;martin.hodo@intel.com&gt;
Fixes: 3e28d37146db ("drm/i915: Move priolist to new i915_sched_engine object")
Cc: Matthew Brost &lt;matthew.brost@intel.com&gt;
Cc: Daniele Ceraolo Spurio &lt;daniele.ceraolospurio@intel.com&gt;
Cc: Tvrtko Ursulin &lt;tursulin@ursulin.net&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.15+
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Signed-off-by: Tvrtko Ursulin &lt;tursulin@ursulin.net&gt;
Link: https://lore.kernel.org/r/20260701114513.221254-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/mst: limit DP MST ESI service loop</title>
<updated>2026-07-06T14:26:00+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-06-25T14:22:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=005771c18c5b2c98cb4e7517661aea460990fd3f'/>
<id>urn:sha1:005771c18c5b2c98cb4e7517661aea460990fd3f</id>
<content type='text'>
The loop in intel_dp_check_mst_status() keeps servicing interrupts
originating from the sink without bound. Add an upper bound to the new
interrupts occurring during interrupt processing to not get stuck on
potentially stuck sink devices. Use arbitrary 32 tries to clear incoming
interrupts in one go.

Discovered using AI-assisted static analysis confirmed by Intel Product
Security.

Note: The condition likely pre-dates the commit in the Fixes: tag, but
this is about as far back as a backport has any chance of
succeeding. Before that, the retry had a goto.

Reported-by: Martin Hodo &lt;martin.hodo@intel.com&gt;
Fixes: 3c0ec2c2d594 ("drm/i915: Flatten intel_dp_check_mst_status() a bit")
Cc: stable@vger.kernel.org # v5.8+
Cc: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Cc: Imre Deak &lt;imre.deak@intel.com&gt;
Reviewed-by: Imre Deak &lt;imre.deak@intel.com&gt;
Link: https://patch.msgid.link/20260625142204.1078287-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU</title>
<updated>2026-07-06T14:25:54+00:00</updated>
<author>
<name>Joonas Lahtinen</name>
<email>joonas.lahtinen@linux.intel.com</email>
</author>
<published>2026-07-01T07:55:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2b56757a9a7456825eb668fde92299e01c5e2721'/>
<id>urn:sha1:2b56757a9a7456825eb668fde92299e01c5e2721</id>
<content type='text'>
Setting context engine slot N into I915_ENGINE_CLASS_INVALID /
I915_ENGINE_CLASS_INVALID_NONE and attempting to apply
I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL.
Fix that.

Discovered using AI-assisted static analysis confirmed by
Intel Product Security.

Reported-by: Martin Hodo &lt;martin.hodo@intel.com&gt;
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)")
Cc: Faith Ekstrand &lt;faith.ekstrand@collabora.com&gt;
Cc: Simona Vetter &lt;simona.vetter@ffwll.ch&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@igalia.com&gt;
Cc: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.15+
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Reviewed-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Link: https://patch.msgid.link/20260701075555.52142-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/ltphy: Fix SSC Enablement bit in PORT_CLOCK_CTL</title>
<updated>2026-07-06T14:25:48+00:00</updated>
<author>
<name>Suraj Kandpal</name>
<email>suraj.kandpal@intel.com</email>
</author>
<published>2026-07-01T09:15:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e91da9053006da622b865e672a4a37439a3bb88b'/>
<id>urn:sha1:e91da9053006da622b865e672a4a37439a3bb88b</id>
<content type='text'>
According to Bspec we only need to write SSC Enable PLL A bit
and leave PLL B bit alone in PORT_CLOCK_CTL register.

Bspec: 74667, 74492
Fixes: 3383ba2479f7 ("drm/i915/ltphy: Enable SSC during port clock programming")
Signed-off-by: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Reviewed-by: Ankit Nautiyal &lt;ankit.k.nautiyal@intel.com&gt;
Link: https://patch.msgid.link/20260701091503.1302226-3-suraj.kandpal@intel.com
(cherry picked from commit 8e27f752037e72ccee9c4a7c4a6202ecf3daf603)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/bios: range check LFP Data Block panel_type2</title>
<updated>2026-07-01T06:12:33+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-06-26T14:01:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2084503f2d087bf956198e7f6eb25b03a7049cb2'/>
<id>urn:sha1:2084503f2d087bf956198e7f6eb25b03a7049cb2</id>
<content type='text'>
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 &lt;martin.hodo@intel.com&gt;
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 &lt;animesh.manna@intel.com&gt;
Cc: Ville Syrjälä &lt;ville.syrjala@intel.com&gt;
Reviewed-by: Michał Grzelak &lt;michal.grzelak@intel.com&gt; # v1
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patch.msgid.link/20260626140155.1389655-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/vrr: require valid min/max vfreq for VRR</title>
<updated>2026-07-01T06:12:30+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-06-25T13:10:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f8a9262c7a6fc2de9802e14b0228114f0333869e'/>
<id>urn:sha1:f8a9262c7a6fc2de9802e14b0228114f0333869e</id>
<content type='text'>
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 &lt;martin.hodo@intel.com&gt;
Fixes: 117cd09ba528 ("drm/i915/display/dp: Compute VRR state in atomic_check")
Cc: stable@vger.kernel.org # v5.12+
Cc: Ankit Nautiyal &lt;ankit.k.nautiyal@intel.com&gt;
Reviewed-by: Ankit Nautiyal &lt;ankit.k.nautiyal@intel.com&gt;
Link: https://patch.msgid.link/20260625131040.1051272-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/hdcp: require monotonically increasing seq_num_v</title>
<updated>2026-06-30T06:35:52+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-06-25T10:44:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=db9e64c983dcb07ff256bd455f258c44aa530ff8'/>
<id>urn:sha1:db9e64c983dcb07ff256bd455f258c44aa530ff8</id>
<content type='text'>
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 &lt;martin.hodo@intel.com&gt;
Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication")
Cc: stable@vger.kernel.org # v5.2+
Cc: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Reviewed-by: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit 58a224375c81179b52558c53d8857b93196d2687)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>drm/i915/hdcp: check streams[] bounds before overflow</title>
<updated>2026-06-30T06:35:49+00:00</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2026-06-25T17:03:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bbb15a6b042d02e5508a02b4847e02d2579ee7bc'/>
<id>urn:sha1:bbb15a6b042d02e5508a02b4847e02d2579ee7bc</id>
<content type='text'>
The data-&gt;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 &lt;martin.hodo@intel.com&gt;
Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data")
Cc: stable@vger.kernel.org # v5.12+
Cc: Anshuman Gupta &lt;anshuman.gupta@intel.com&gt;
Cc: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Reviewed-by: Suraj Kandpal &lt;suraj.kandpal@intel.com&gt;
Link: https://patch.msgid.link/20260625170304.1104723-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
(cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
</content>
</entry>
</feed>
