<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/gpu, branch v4.4.177</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>drm/radeon/evergreen_cs: fix missing break in switch statement</title>
<updated>2019-03-23T07:44:40+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2019-02-15T20:29:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=71e005f009ffeb3372e41ed58cc4d3b6453cebfd'/>
<id>71e005f009ffeb3372e41ed58cc4d3b6453cebfd</id>
<content type='text'>
commit cc5034a5d293dd620484d1d836aa16c6764a1c8c upstream.

Add missing break statement in order to prevent the code from falling
through to case CB_TARGET_MASK.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cc5034a5d293dd620484d1d836aa16c6764a1c8c upstream.

Add missing break statement in order to prevent the code from falling
through to case CB_TARGET_MASK.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: dd220a00e8bd ("drm/radeon/kms: add support for streamout v7")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>gpu: ipu-v3: Fix CSI offsets for imx53</title>
<updated>2019-03-23T07:44:32+00:00</updated>
<author>
<name>Steve Longerbeam</name>
<email>slongerbeam@gmail.com</email>
</author>
<published>2018-10-17T00:31:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e212aa684767a43ed2fe3f0d468f2e982662d5fb'/>
<id>e212aa684767a43ed2fe3f0d468f2e982662d5fb</id>
<content type='text'>
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]

The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e030000 and 0x1e038000 respectively.

Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")

Signed-off-by: Steve Longerbeam &lt;slongerbeam@gmail.com&gt;
Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit bb867d219fda7fbaabea3314702474c4eac2b91d ]

The CSI offsets are wrong for both CSI0 and CSI1. They are at
physical address 0x1e030000 and 0x1e038000 respectively.

Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")

Signed-off-by: Steve Longerbeam &lt;slongerbeam@gmail.com&gt;
Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>gpu: ipu-v3: Fix i.MX51 CSI control registers offset</title>
<updated>2019-03-23T07:44:32+00:00</updated>
<author>
<name>Alexander Shiyan</name>
<email>shc_work@mail.ru</email>
</author>
<published>2018-12-20T08:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8512f804fd88b43bb2f2bb67d17993fc57bd3d58'/>
<id>8512f804fd88b43bb2f2bb67d17993fc57bd3d58</id>
<content type='text'>
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]

The CSI0/CSI1 registers offset is at +0xe030000/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.

Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")

Signed-off-by: Alexander Shiyan &lt;shc_work@mail.ru&gt;
Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 2c0408dd0d8906b26fe8023889af7adf5e68b2c2 ]

The CSI0/CSI1 registers offset is at +0xe030000/+0xe038000 relative
to the control module registers on IPUv3EX.
This patch fixes wrong values for i.MX51 CSI0/CSI1.

Fixes: 2ffd48f2e7 ("gpu: ipu-v3: Add Camera Sensor Interface unit")

Signed-off-by: Alexander Shiyan &lt;shc_work@mail.ru&gt;
Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/msm: Unblock writer if reader closes file</title>
<updated>2019-03-23T07:44:18+00:00</updated>
<author>
<name>Kristian H. Kristensen</name>
<email>hoegsberg@gmail.com</email>
</author>
<published>2018-12-19T16:57:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=59f6c707704a5e7c2f1c03842f28366697901af5'/>
<id>59f6c707704a5e7c2f1c03842f28366697901af5</id>
<content type='text'>
[ Upstream commit 99c66bc051e7407fe0bf0607b142ec0be1a1d1dd ]

Prevents deadlock when fifo is full and reader closes file.

Signed-off-by: Kristian H. Kristensen &lt;hoegsberg@chromium.org&gt;
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 99c66bc051e7407fe0bf0607b142ec0be1a1d1dd ]

Prevents deadlock when fifo is full and reader closes file.

Signed-off-by: Kristian H. Kristensen &lt;hoegsberg@chromium.org&gt;
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user</title>
<updated>2019-02-20T09:13:19+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2019-01-31T09:55:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=697c6f72c4935a6361fb36d7d80fa6a8f958c271'/>
<id>697c6f72c4935a6361fb36d7d80fa6a8f958c271</id>
<content type='text'>
commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.

The function was unconditionally returning 0, and a caller would have to
rely on the returned fence pointer being NULL to detect errors. However,
the function vmw_execbuf_copy_fence_user() would expect a non-zero error
code in that case and would BUG otherwise.

So make sure we return a proper non-zero error code if the fence pointer
returned is NULL.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: ae2a104058e2: ("vmwgfx: Implement fence objects")
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Deepak Rawat &lt;drawat@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.

The function was unconditionally returning 0, and a caller would have to
rely on the returned fence pointer being NULL to detect errors. However,
the function vmw_execbuf_copy_fence_user() would expect a non-zero error
code in that case and would BUG otherwise.

So make sure we return a proper non-zero error code if the fence pointer
returned is NULL.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: ae2a104058e2: ("vmwgfx: Implement fence objects")
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Deepak Rawat &lt;drawat@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix setting of dma masks</title>
<updated>2019-02-20T09:13:19+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2019-01-28T09:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=6bcca0bc47652a55ff1d2a71f50665661f24dfaa'/>
<id>6bcca0bc47652a55ff1d2a71f50665661f24dfaa</id>
<content type='text'>
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.

Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initially set to 64 bits.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Deepak Rawat &lt;drawat@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.

Previously we set only the dma mask and not the coherent mask. Fix that.
Also, for clarity, make sure both are initially set to 64 bits.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Deepak Rawat &lt;drawat@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/modes: Prevent division by zero htotal</title>
<updated>2019-02-20T09:13:19+00:00</updated>
<author>
<name>Tina Zhang</name>
<email>tina.zhang@intel.com</email>
</author>
<published>2019-01-23T07:28:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f1cd557ecbbfc1338c38e15f19f519854a0b4799'/>
<id>f1cd557ecbbfc1338c38e15f19f519854a0b4799</id>
<content type='text'>
commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.

This patch prevents division by zero htotal.

In a follow-up mail Tina writes:

&gt; &gt; How did you manage to get here with htotal == 0? This needs backtraces (or if
&gt; &gt; this is just about static checkers, a mention of that).
&gt; &gt; -Daniel
&gt;
&gt; In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
&gt; (a.k.a htotal=0), then we met the following kernel panic:
&gt;
&gt; [   32.832048] divide error: 0000 [#1] SMP PTI
&gt; [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
&gt; [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
&gt; [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
&gt; [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 &lt;f7&gt; f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
&gt; [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
&gt; [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
&gt; [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
&gt; [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
&gt; [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
&gt; [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
&gt; [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
&gt; [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt; [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
&gt; [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
&gt; [   32.836004] Call Trace:
&gt; [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
&gt; [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
&gt; [   32.836004]  intel_modeset_init+0x905/0x1db0
&gt; [   32.836004]  i915_driver_load+0xb8c/0x1120
&gt; [   32.836004]  i915_pci_probe+0x4d/0xb0
&gt; [   32.836004]  local_pci_probe+0x44/0xa0
&gt; [   32.836004]  ? pci_assign_irq+0x27/0x130
&gt; [   32.836004]  pci_device_probe+0x102/0x1c0
&gt; [   32.836004]  driver_probe_device+0x2b8/0x480
&gt; [   32.836004]  __driver_attach+0x109/0x110
&gt; [   32.836004]  ? driver_probe_device+0x480/0x480
&gt; [   32.836004]  bus_for_each_dev+0x67/0xc0
&gt; [   32.836004]  ? klist_add_tail+0x3b/0x70
&gt; [   32.836004]  bus_add_driver+0x1e8/0x260
&gt; [   32.836004]  driver_register+0x5b/0xe0
&gt; [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
&gt; [   32.836004]  do_one_initcall+0x4d/0x1eb
&gt; [   32.836004]  kernel_init_freeable+0x197/0x237
&gt; [   32.836004]  ? rest_init+0xd0/0xd0
&gt; [   32.836004]  kernel_init+0xa/0x110
&gt; [   32.836004]  ret_from_fork+0x35/0x40
&gt; [   32.836004] Modules linked in:
&gt; [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
&gt; [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
&gt; [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 &lt;f7&gt; f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
&gt; [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
&gt; [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
&gt; [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
&gt; [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
&gt; [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
&gt; [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
&gt; [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
&gt; [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt; [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
&gt; [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
&gt; [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
&gt;
&gt; Since drm_mode_hsync() has the logic to check mode-&gt;htotal, I just extend it to cover the case htotal==0.

Signed-off-by: Tina Zhang &lt;tina.zhang@intel.com&gt;
Cc: Adam Jackson &lt;ajax@redhat.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
[danvet: Add additional explanations + cc: stable.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.

This patch prevents division by zero htotal.

In a follow-up mail Tina writes:

&gt; &gt; How did you manage to get here with htotal == 0? This needs backtraces (or if
&gt; &gt; this is just about static checkers, a mention of that).
&gt; &gt; -Daniel
&gt;
&gt; In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
&gt; (a.k.a htotal=0), then we met the following kernel panic:
&gt;
&gt; [   32.832048] divide error: 0000 [#1] SMP PTI
&gt; [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
&gt; [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
&gt; [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
&gt; [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 &lt;f7&gt; f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
&gt; [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
&gt; [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
&gt; [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
&gt; [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
&gt; [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
&gt; [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
&gt; [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
&gt; [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt; [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
&gt; [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
&gt; [   32.836004] Call Trace:
&gt; [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
&gt; [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
&gt; [   32.836004]  intel_modeset_init+0x905/0x1db0
&gt; [   32.836004]  i915_driver_load+0xb8c/0x1120
&gt; [   32.836004]  i915_pci_probe+0x4d/0xb0
&gt; [   32.836004]  local_pci_probe+0x44/0xa0
&gt; [   32.836004]  ? pci_assign_irq+0x27/0x130
&gt; [   32.836004]  pci_device_probe+0x102/0x1c0
&gt; [   32.836004]  driver_probe_device+0x2b8/0x480
&gt; [   32.836004]  __driver_attach+0x109/0x110
&gt; [   32.836004]  ? driver_probe_device+0x480/0x480
&gt; [   32.836004]  bus_for_each_dev+0x67/0xc0
&gt; [   32.836004]  ? klist_add_tail+0x3b/0x70
&gt; [   32.836004]  bus_add_driver+0x1e8/0x260
&gt; [   32.836004]  driver_register+0x5b/0xe0
&gt; [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
&gt; [   32.836004]  do_one_initcall+0x4d/0x1eb
&gt; [   32.836004]  kernel_init_freeable+0x197/0x237
&gt; [   32.836004]  ? rest_init+0xd0/0xd0
&gt; [   32.836004]  kernel_init+0xa/0x110
&gt; [   32.836004]  ret_from_fork+0x35/0x40
&gt; [   32.836004] Modules linked in:
&gt; [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
&gt; [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
&gt; [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 &lt;f7&gt; f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
&gt; [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
&gt; [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
&gt; [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
&gt; [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
&gt; [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
&gt; [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
&gt; [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
&gt; [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt; [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
&gt; [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt; [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
&gt; [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
&gt;
&gt; Since drm_mode_hsync() has the logic to check mode-&gt;htotal, I just extend it to cover the case htotal==0.

Signed-off-by: Tina Zhang &lt;tina.zhang@intel.com&gt;
Cc: Adam Jackson &lt;ajax@redhat.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
[danvet: Add additional explanations + cc: stable.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/bufs: Fix Spectre v1 vulnerability</title>
<updated>2019-02-20T09:13:03+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-10-16T09:55:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3f951709eb2412974077d50b8e14cbc675b246a4'/>
<id>3f951709eb2412974077d50b8e14cbc675b246a4</id>
<content type='text'>
[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma-&gt;buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma-&gt;buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&amp;m=152449131114778&amp;w=2

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embeddedor.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a37805098900a6e73a55b3a43b7d3bcd987bb3f4 ]

idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_bufs.c:1420 drm_legacy_freebufs() warn: potential
spectre issue 'dma-&gt;buflist' [r] (local cap)

Fix this by sanitizing idx before using it to index dma-&gt;buflist

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&amp;m=152449131114778&amp;w=2

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181016095549.GA23586@embeddedor.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock</title>
<updated>2019-01-26T08:42:52+00:00</updated>
<author>
<name>Ivan Mironov</name>
<email>mironov.ivan@gmail.com</email>
</author>
<published>2019-01-08T07:23:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e896840a8a6680e53dcaafc398010b0c6e40a213'/>
<id>e896840a8a6680e53dcaafc398010b0c6e40a213</id>
<content type='text'>
commit 66a8d5bfb518f9f12d47e1d2dce1732279f9451e upstream.

Strict requirement of pixclock to be zero breaks support of SDL 1.2
which contains hardcoded table of supported video modes with non-zero
pixclock values[1].

To better understand which pixclock values are considered valid and how
driver should handle these values, I briefly examined few existing fbdev
drivers and documentation in Documentation/fb/. And it looks like there
are no strict rules on that and actual behaviour varies:

	* some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
	* some treat (pixclock == 0) as invalid value which leads to
	  -EINVAL (clps711x-fb.c);
	* some pass converted pixclock value to hardware (uvesafb.c);
	* some are trying to find nearest value from predefined table
          (vga16fb.c, video_gx.c).

Given this, I believe that it should be safe to just ignore this value if
changing is not supported. It seems that any portable fbdev application
which was not written only for one specific device working under one
specific kernel version should not rely on any particular behaviour of
pixclock anyway.

However, while enabling SDL1 applications to work out of the box when
there is no /etc/fb.modes with valid settings, this change affects the
video mode choosing logic in SDL. Depending on current screen
resolution, contents of /etc/fb.modes and resolution requested by
application, this may lead to user-visible difference (not always):
image will be displayed in a right way, but it will be aligned to the
left instead of center. There is no "right behaviour" here as well, as
emulated fbdev, opposing to old fbdev drivers, simply ignores any
requsts of video mode changes with resolutions smaller than current.

The easiest way to reproduce this problem is to install sdl-sopwith[2],
remove /etc/fb.modes file if it exists, and then try to run sopwith
from console without X. At least in Fedora 29, sopwith may be simply
installed from standard repositories.

[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
[2] http://sdl-sopwith.sourceforge.net/

Signed-off-by: Ivan Mironov &lt;mironov.ivan@gmail.com&gt;
Cc: stable@vger.kernel.org
Fixes: 79e539453b34e ("DRM: i915: add mode setting support")
Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware")
Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)")
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 66a8d5bfb518f9f12d47e1d2dce1732279f9451e upstream.

Strict requirement of pixclock to be zero breaks support of SDL 1.2
which contains hardcoded table of supported video modes with non-zero
pixclock values[1].

To better understand which pixclock values are considered valid and how
driver should handle these values, I briefly examined few existing fbdev
drivers and documentation in Documentation/fb/. And it looks like there
are no strict rules on that and actual behaviour varies:

	* some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
	* some treat (pixclock == 0) as invalid value which leads to
	  -EINVAL (clps711x-fb.c);
	* some pass converted pixclock value to hardware (uvesafb.c);
	* some are trying to find nearest value from predefined table
          (vga16fb.c, video_gx.c).

Given this, I believe that it should be safe to just ignore this value if
changing is not supported. It seems that any portable fbdev application
which was not written only for one specific device working under one
specific kernel version should not rely on any particular behaviour of
pixclock anyway.

However, while enabling SDL1 applications to work out of the box when
there is no /etc/fb.modes with valid settings, this change affects the
video mode choosing logic in SDL. Depending on current screen
resolution, contents of /etc/fb.modes and resolution requested by
application, this may lead to user-visible difference (not always):
image will be displayed in a right way, but it will be aligned to the
left instead of center. There is no "right behaviour" here as well, as
emulated fbdev, opposing to old fbdev drivers, simply ignores any
requsts of video mode changes with resolutions smaller than current.

The easiest way to reproduce this problem is to install sdl-sopwith[2],
remove /etc/fb.modes file if it exists, and then try to run sopwith
from console without X. At least in Fedora 29, sopwith may be simply
installed from standard repositories.

[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
[2] http://sdl-sopwith.sourceforge.net/

Signed-off-by: Ivan Mironov &lt;mironov.ivan@gmail.com&gt;
Cc: stable@vger.kernel.org
Fixes: 79e539453b34e ("DRM: i915: add mode setting support")
Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware")
Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)")
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</pre>
</div>
</content>
</entry>
<entry>
<title>drm/ioctl: Fix Spectre v1 vulnerabilities</title>
<updated>2019-01-13T09:05:27+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-12-20T00:00:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=a2a840d6dcae960c2dfdf3fcb1b759e1b7d90663'/>
<id>a2a840d6dcae960c2dfdf3fcb1b759e1b7d90663</id>
<content type='text'>
commit 505b5240329b922f21f91d5b5d1e535c805eca6d upstream.

nr is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue 'dev-&gt;driver-&gt;ioctls' [r]
drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue 'drm_ioctls' [r] (local cap)
drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre issue 'drm_ioctls' [r] (local cap)

Fix this by sanitizing nr before using it to index dev-&gt;driver-&gt;ioctls
and drm_ioctls.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&amp;m=152449131114778&amp;w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181220000015.GA18973@embeddedor
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 505b5240329b922f21f91d5b5d1e535c805eca6d upstream.

nr is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue 'dev-&gt;driver-&gt;ioctls' [r]
drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue 'drm_ioctls' [r] (local cap)
drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre issue 'drm_ioctls' [r] (local cap)

Fix this by sanitizing nr before using it to index dev-&gt;driver-&gt;ioctls
and drm_ioctls.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&amp;m=152449131114778&amp;w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20181220000015.GA18973@embeddedor
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
