<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v5.4.230</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.230</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.230'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-01-24T06:18:01+00:00</updated>
<entry>
<title>drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix</title>
<updated>2023-01-24T06:18:01+00:00</updated>
<author>
<name>Joshua Ashton</name>
<email>joshua@froggi.es</email>
</author>
<published>2023-01-10T22:50:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b1375fac0de483dc2f2423279731ea8cfb4111a'/>
<id>urn:sha1:2b1375fac0de483dc2f2423279731ea8cfb4111a</id>
<content type='text'>
commit 973a9c810c785ac270a6d50d8cf862b0c1643a10 upstream.

The YCC conversion matrix for RGB -&gt; COLOR_SPACE_YCBCR2020_TYPE is
missing the values for the fourth column of the matrix.

The fourth column of the matrix is essentially just a value that is
added given that the color is 3 components in size.
These values are needed to bias the chroma from the [-1, 1] -&gt; [0, 1]
range.

This fixes color being very green when using Gamescope HDR on HDMI
output which prefers YCC 4:4:4.

Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")
Reviewed-by: Melissa Wen &lt;mwen@igalia.com&gt;
Signed-off-by: Joshua Ashton &lt;joshua@froggi.es&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix set scaling doesn's work</title>
<updated>2023-01-24T06:18:01+00:00</updated>
<author>
<name>hongao</name>
<email>hongao@uniontech.com</email>
</author>
<published>2022-11-22T11:20:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=763a74e1de744e455b7edca326e49de162f1b995'/>
<id>urn:sha1:763a74e1de744e455b7edca326e49de162f1b995</id>
<content type='text'>
commit 040625ab82ce6dca7772cb3867fe5c9eb279a344 upstream.

[Why]
Setting scaling does not correctly update CRTC state. As a result
dc stream state's src (composition area) &amp;&amp; dest (addressable area)
was not calculated as expected. This causes set scaling doesn's work.

[How]
Correctly update CRTC state when setting scaling property.

Reviewed-by: Harry Wentland &lt;harry.wentland@amd.com&gt;
Tested-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: hongao &lt;hongao@uniontech.com&gt;
Signed-off-by: Rodrigo Siqueira &lt;Rodrigo.Siqueira@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: re-disable RC6p on Sandy Bridge</title>
<updated>2023-01-24T06:18:01+00:00</updated>
<author>
<name>Sasa Dragic</name>
<email>sasa.dragic@gmail.com</email>
</author>
<published>2022-12-19T17:29:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39e0844a1e960a17e142d7147f94215e1d5bf200'/>
<id>urn:sha1:39e0844a1e960a17e142d7147f94215e1d5bf200</id>
<content type='text'>
commit 67b0b4ed259e425b7eed09da75b42c80682ca003 upstream.

RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
and GPU hangs.

Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
RC6p on Sandy Bridge").

Signed-off-by: Sasa Dragic &lt;sasa.dragic@gmail.com&gt;
Signed-off-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221219172927.9603-2-sasa.dragic@gmail.com
Fixes: fb6db0f5bf1d ("drm/i915: Remove unsafe i915.enable_rc6")
Fixes: 13c5a577b342 ("drm/i915/gt: Select the deepest available parking mode for rc6")
Cc: stable@vger.kernel.org
Reviewed-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
(cherry picked from commit 0c8a6e9ea232c221976a0670256bd861408d9917)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915/gt: Reset twice</title>
<updated>2023-01-24T06:17:59+00:00</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2022-12-12T16:13:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e60730280b572b1882ba61152bcdbeaee4e3fe91'/>
<id>urn:sha1:e60730280b572b1882ba61152bcdbeaee4e3fe91</id>
<content type='text'>
[ Upstream commit d3de5616d36462a646f5b360ba82d3b09ff668eb ]

After applying an engine reset, on some platforms like Jasperlake, we
occasionally detect that the engine state is not cleared until shortly
after the resume. As we try to resume the engine with volatile internal
state, the first request fails with a spurious CS event (it looks like
it reports a lite-restore to the hung context, instead of the expected
idle-&gt;active context switch).

Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: stable@vger.kernel.org
Cc: Mika Kuoppala &lt;mika.kuoppala@linux.intel.com&gt;
Signed-off-by: Andi Shyti &lt;andi.shyti@linux.intel.com&gt;
Reviewed-by: Gwan-gyeong Mun &lt;gwan-gyeong.mun@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221212161338.1007659-1-andi.shyti@linux.intel.com
(cherry picked from commit 3db9d590557da3aa2c952f2fecd3e9b703dad790)
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/virtio: Fix GEM handle creation UAF</title>
<updated>2023-01-18T10:42:05+00:00</updated>
<author>
<name>Rob Clark</name>
<email>robdclark@chromium.org</email>
</author>
<published>2022-12-16T23:33:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73'/>
<id>urn:sha1:d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73</id>
<content type='text'>
[ Upstream commit 52531258318ed59a2dc5a43df2eaf0eb1d65438e ]

Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference.  For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.

Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Reviewed-by: Chia-I Wu &lt;olvaffe@gmail.com&gt;
Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Osipenko &lt;dmitry.osipenko@collabora.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdclark@gmail.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/msm/adreno: Make adreno quirks not overwrite each other</title>
<updated>2023-01-18T10:42:02+00:00</updated>
<author>
<name>Konrad Dybcio</name>
<email>konrad.dybcio@linaro.org</email>
</author>
<published>2023-01-02T10:02:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ad759df6a6f873a7cc116b2e88759e790a7f04f'/>
<id>urn:sha1:1ad759df6a6f873a7cc116b2e88759e790a7f04f</id>
<content type='text'>
commit 13ef096e342b00e30b95a90c6c13eee1f0bec4c5 upstream.

So far the adreno quirks have all been assigned with an OR operator,
which is problematic, because they were assigned consecutive integer
values, which makes checking them with an AND operator kind of no bueno..

Switch to using BIT(n) so that only the quirks that the programmer chose
are taken into account when evaluating info-&gt;quirks &amp; ADRENO_QUIRK_...

Fixes: 370063ee427a ("drm/msm/adreno: Add A540 support")
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Marijn Suijten &lt;marijn.suijten@somainline.org&gt;
Reviewed-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Konrad Dybcio &lt;konrad.dybcio@linaro.org&gt;
Reviewed-by: Akhil P Oommen &lt;quic_akhilpo@quicinc.com&gt;
Patchwork: https://patchwork.freedesktop.org/patch/516456/
Link: https://lore.kernel.org/r/20230102100201.77286-1-konrad.dybcio@linaro.org
Signed-off-by: Rob Clark &lt;robdclark@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()</title>
<updated>2023-01-18T10:41:58+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>error27@gmail.com</email>
</author>
<published>2022-11-15T13:15:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3cb1ee82e4edf2ff3877c76f9f7ee909759763e2'/>
<id>urn:sha1:3cb1ee82e4edf2ff3877c76f9f7ee909759763e2</id>
<content type='text'>
[ Upstream commit 3792fc508c095abd84b10ceae12bd773e61fdc36 ]

Call intel_vgpu_unpin_mm() on this error path.

Fixes: 418741480809 ("drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled.")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/Y3OQ5tgZIVxyQ/WV@kili
Reviewed-by: Zhenyu Wang &lt;zhenyuw@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Validate the box size for the snooped cursor</title>
<updated>2023-01-18T10:41:50+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-10-26T03:19:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94b283341f9f3f0ed56a360533766377a01540e0'/>
<id>urn:sha1:94b283341f9f3f0ed56a360533766377a01540e0</id>
<content type='text'>
commit 4cf949c7fafe21e085a4ee386bb2dade9067316e upstream.

Invalid userspace dma surface copies could potentially overflow
the memcpy from the surface to the snooped image leading to crashes.
To fix it the dimensions of the copybox have to be validated
against the expected size of the snooped cursor.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Fixes: 2ac863719e51 ("vmwgfx: Snoop DMA transfers with non-covering sizes")
Cc: &lt;stable@vger.kernel.org&gt; # v3.2+
Reviewed-by: Michael Banack &lt;banackm@vmware.com&gt;
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/connector: send hotplug uevent on connector cleanup</title>
<updated>2023-01-18T10:41:50+00:00</updated>
<author>
<name>Simon Ser</name>
<email>contact@emersion.fr</email>
</author>
<published>2022-10-17T15:32:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=eea62f0461a947f2beedead58753dfd693eb571e'/>
<id>urn:sha1:eea62f0461a947f2beedead58753dfd693eb571e</id>
<content type='text'>
commit 6fdc2d490ea1369d17afd7e6eb66fecc5b7209bc upstream.

A typical DP-MST unplug removes a KMS connector. However care must
be taken to properly synchronize with user-space. The expected
sequence of events is the following:

1. The kernel notices that the DP-MST port is gone.
2. The kernel marks the connector as disconnected, then sends a
   uevent to make user-space re-scan the connector list.
3. User-space notices the connector goes from connected to disconnected,
   disables it.
4. Kernel handles the IOCTL disabling the connector. On success,
   the very last reference to the struct drm_connector is dropped and
   drm_connector_cleanup() is called.
5. The connector is removed from the list, and a uevent is sent to tell
   user-space that the connector disappeared.

The very last step was missing. As a result, user-space thought the
connector still existed and could try to disable it again. Since the
kernel no longer knows about the connector, that would end up with
EINVAL and confused user-space.

Fix this by sending a hotplug uevent from drm_connector_cleanup().

Signed-off-by: Simon Ser &lt;contact@emersion.fr&gt;
Cc: stable@vger.kernel.org
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Lyude Paul &lt;lyude@redhat.com&gt;
Cc: Jonas Ådahl &lt;jadahl@redhat.com&gt;
Tested-by: Jonas Ådahl &lt;jadahl@redhat.com&gt;
Reviewed-by: Lyude Paul &lt;lyude@redhat.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20221017153150.60675-2-contact@emersion.fr
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()</title>
<updated>2023-01-18T10:41:39+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>nathan@kernel.org</email>
</author>
<published>2022-11-02T15:56:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=511b48ee8e4aec2d03d2af06b363d9eb3230b017'/>
<id>urn:sha1:511b48ee8e4aec2d03d2af06b363d9eb3230b017</id>
<content type='text'>
[ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .mode_valid = sti_hda_connector_mode_valid,
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .mode_valid = sti_dvo_connector_mode_valid,
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .mode_valid = sti_hdmi_connector_mode_valid,
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-&gt;mode_valid() in 'struct drm_connector_helper_funcs' expects a return
type of 'enum drm_mode_status', not 'int'. Adjust the return type of
sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
resolve the warning and CFI failure.

Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Signed-off-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: https://lore.kernel.org/r/20221102155623.3042869-1-nathan@kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
