<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/video/fbdev, branch v4.4.171</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.171</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.171'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-12-17T20:55:17+00:00</updated>
<entry>
<title>matroxfb: fix size of memcpy</title>
<updated>2018-12-17T20:55:17+00:00</updated>
<author>
<name>Sudip Mukherjee</name>
<email>sudipm.mukherjee@gmail.com</email>
</author>
<published>2016-08-25T17:44:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed8c3cb1e66ac583ae461fef25b0cd01df1e50e7'/>
<id>urn:sha1:ed8c3cb1e66ac583ae461fef25b0cd01df1e50e7</id>
<content type='text'>
commit 59921b239056fb6389a865083284e00ce0518db6 upstream.

hw-&gt;DACreg has a size of 80 bytes and MGADACbpp32 has 21. So when
memcpy copies MGADACbpp32 to hw-&gt;DACreg it copies 80 bytes but
only 21 bytes are valid.

Signed-off-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm: replace get_user_pages_unlocked() write/force parameters with gup_flags</title>
<updated>2018-12-17T20:55:16+00:00</updated>
<author>
<name>Lorenzo Stoakes</name>
<email>lstoakes@gmail.com</email>
</author>
<published>2016-10-13T00:20:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b29980eb75bc7dcb23ed0436fe805ac6e684542'/>
<id>urn:sha1:2b29980eb75bc7dcb23ed0436fe805ac6e684542</id>
<content type='text'>
commit c164154f66f0c9b02673f07aa4f044f1d9c70274 upstream.

This removes the 'write' and 'force' use from get_user_pages_unlocked()
and replaces them with 'gup_flags' to make the use of FOLL_FORCE
explicit in callers as use of this flag can result in surprising
behaviour (and hence bugs) within the mm subsystem.

Signed-off-by: Lorenzo Stoakes &lt;lstoakes@gmail.com&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
[bwh: Backported to 4.4:
 - Also update calls from process_vm_rw_single_vec() and async_pf_execute()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mach64: fix image corruption due to reading accelerator registers</title>
<updated>2018-11-21T08:27:42+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2018-10-08T10:57:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ffd631735f5e6bf565aef94b098e4821eb105c1'/>
<id>urn:sha1:1ffd631735f5e6bf565aef94b098e4821eb105c1</id>
<content type='text'>
commit c09bcc91bb94ed91f1391bffcbe294963d605732 upstream.

Reading the registers without waiting for engine idle returns
unpredictable values. These unpredictable values result in display
corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
never ever clear the bit, resulting in display corruption.

We don't want to wait for idle because it would degrade performance, so
this patch modifies the driver so that it never reads accelerator
registers.

HOST_CNTL doesn't have to be read, we can just write it with
HOST_BYTE_ALIGN because no other part of the driver cares if
HOST_BYTE_ALIGN is set.

DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
with the default value and in atyfb_imageblit with the value set according
to the source image data.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reviewed-by: Ville Syrjälä &lt;syrjala@sci.fi&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mach64: fix display corruption on big endian machines</title>
<updated>2018-11-21T08:27:42+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2018-10-08T10:57:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d4ce43c13b799653ad1e14820f182e28c7f6f49'/>
<id>urn:sha1:5d4ce43c13b799653ad1e14820f182e28c7f6f49</id>
<content type='text'>
commit 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 upstream.

The code for manual bit triple is not endian-clean. It builds the variable
"hostdword" using byte accesses, therefore we must read the variable with
"le32_to_cpu".

The patch also enables (hardware or software) bit triple only if the image
is monochrome (image-&gt;depth). If we want to blit full-color image, we
shouldn't use the triple code.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Reviewed-by: Ville Syrjälä &lt;syrjala@sci.fi&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>video: fbdev: pxa3xx_gcu: fix error return code in pxa3xx_gcu_probe()</title>
<updated>2018-11-10T15:41:39+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2017-08-21T14:49:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9954f1884eec0c584136a08290a62d996fd010ea'/>
<id>urn:sha1:9954f1884eec0c584136a08290a62d996fd010ea</id>
<content type='text'>
[ Upstream commit 7588f1ecc5f0c914e669d8afb6525f47cd1c4355 ]

platform_get_irq() returns an error code, but the pxa3xx_gcu driver
ignores it and always returns -ENODEV. This is not correct and,
prevents -EPROBE_DEFER from being propagated properly.

Also, notice that platform_get_irq() no longer returns 0 on error:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af

Print and propagate the return value of platform_get_irq on failure.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pxa168fb: prepare the clock</title>
<updated>2018-11-10T15:41:33+00:00</updated>
<author>
<name>Lubomir Rintel</name>
<email>lkundrak@v3.sk</email>
</author>
<published>2018-09-26T16:11:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=df2d090bc5df33e92b43b2134d118fc60e2e0c97'/>
<id>urn:sha1:df2d090bc5df33e92b43b2134d118fc60e2e0c97</id>
<content type='text'>
[ Upstream commit d85536cde91fcfed6fb8d983783bd2b92c843939 ]

Add missing prepare/unprepare operations for fbi-&gt;clk,
this fixes following kernel warning:

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:874 clk_core_enable+0x2c/0x1b0
  Enabling unprepared disp0_clk
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0-rc8-00032-g02b43ddd4f21-dirty #25
  Hardware name: Marvell MMP2 (Device Tree Support)
  [&lt;c010f7cc&gt;] (unwind_backtrace) from [&lt;c010cc6c&gt;] (show_stack+0x10/0x14)
  [&lt;c010cc6c&gt;] (show_stack) from [&lt;c011dab4&gt;] (__warn+0xd8/0xf0)
  [&lt;c011dab4&gt;] (__warn) from [&lt;c011db10&gt;] (warn_slowpath_fmt+0x44/0x6c)
  [&lt;c011db10&gt;] (warn_slowpath_fmt) from [&lt;c043898c&gt;] (clk_core_enable+0x2c/0x1b0)
  [&lt;c043898c&gt;] (clk_core_enable) from [&lt;c0439ec8&gt;] (clk_core_enable_lock+0x18/0x2c)
  [&lt;c0439ec8&gt;] (clk_core_enable_lock) from [&lt;c0436698&gt;] (pxa168fb_probe+0x464/0x6ac)
  [&lt;c0436698&gt;] (pxa168fb_probe) from [&lt;c04779a0&gt;] (platform_drv_probe+0x48/0x94)
  [&lt;c04779a0&gt;] (platform_drv_probe) from [&lt;c0475bec&gt;] (driver_probe_device+0x328/0x470)
  [&lt;c0475bec&gt;] (driver_probe_device) from [&lt;c0475de4&gt;] (__driver_attach+0xb0/0x124)
  [&lt;c0475de4&gt;] (__driver_attach) from [&lt;c0473c38&gt;] (bus_for_each_dev+0x64/0xa0)
  [&lt;c0473c38&gt;] (bus_for_each_dev) from [&lt;c0474ee0&gt;] (bus_add_driver+0x1b8/0x230)
  [&lt;c0474ee0&gt;] (bus_add_driver) from [&lt;c0476a20&gt;] (driver_register+0xac/0xf0)
  [&lt;c0476a20&gt;] (driver_register) from [&lt;c0102dd4&gt;] (do_one_initcall+0xb8/0x1f0)
  [&lt;c0102dd4&gt;] (do_one_initcall) from [&lt;c0b010a0&gt;] (kernel_init_freeable+0x294/0x2e0)
  [&lt;c0b010a0&gt;] (kernel_init_freeable) from [&lt;c07e9eb8&gt;] (kernel_init+0x8/0x10c)
  [&lt;c07e9eb8&gt;] (kernel_init) from [&lt;c01010e8&gt;] (ret_from_fork+0x14/0x2c)
  Exception stack(0xd008bfb0 to 0xd008bff8)
  bfa0:                                     00000000 00000000 00000000 00000000
  bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
  ---[ end trace c0af40f9e2ed7cb4 ]---

Signed-off-by: Lubomir Rintel &lt;lkundrak@v3.sk&gt;
[b.zolnierkie: enhance patch description a bit]
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mach64: detect the dot clock divider correctly on sparc</title>
<updated>2018-10-20T07:52:34+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2018-08-17T19:19:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f41f387b0f44fd5ba325d893edead8b52314437'/>
<id>urn:sha1:2f41f387b0f44fd5ba325d893edead8b52314437</id>
<content type='text'>
commit 76ebebd2464c5c8a4453c98b6dbf9c95a599e810 upstream.

On Sun Ultra 5, it happens that the dot clock is not set up properly for
some videomodes. For example, if we set the videomode "r1024x768x60" in
the firmware, Linux would incorrectly set a videomode with refresh rate
180Hz when booting (suprisingly, my LCD monitor can display it, although
display quality is very low).

The reason is this: Older mach64 cards set the divider in the register
VCLK_POST_DIV. The register has four 2-bit fields (the field that is
actually used is specified in the lowest two bits of the register
CLOCK_CNTL). The 2 bits select divider "1, 2, 4, 8". On newer mach64 cards,
there's another bit added - the top four bits of PLL_EXT_CNTL extend the
divider selection, so we have possible dividers "1, 2, 4, 8, 3, 5, 6, 12".
The Linux driver clears the top four bits of PLL_EXT_CNTL and never sets
them, so it can work regardless if the card supports them. However, the
sparc64 firmware may set these extended dividers during boot - and the
mach64 driver detects incorrect dot clock in this case.

This patch makes the driver read the additional divider bit from
PLL_EXT_CNTL and calculate the initial refresh rate properly.

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Cc: stable@vger.kernel.org
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
Reviewed-by: Ville Syrjälä &lt;syrjala@sci.fi&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fbdev/omapfb: fix omapfb_memory_read infoleak</title>
<updated>2018-10-13T07:11:31+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2018-09-26T16:11:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=937b51457b5fd9560a2ddb300b5dfbec87082919'/>
<id>urn:sha1:937b51457b5fd9560a2ddb300b5dfbec87082919</id>
<content type='text'>
commit 1bafcbf59fed92af58955024452f45430d3898c5 upstream.

OMAPFB_MEMORY_READ ioctl reads pixels from the LCD's memory and copies
them to a userspace buffer. The code has two issues:

- The user provided width and height could be large enough to overflow
  the calculations
- The copy_to_user() can copy uninitialized memory to the userspace,
  which might contain sensitive kernel information.

Fix these by limiting the width &amp; height parameters, and only copying
the amount of data that we actually received from the LCD.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reported-by: Jann Horn &lt;jannh@google.com&gt;
Cc: stable@vger.kernel.org
Cc: security@kernel.org
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Jann Horn &lt;jannh@google.com&gt;
Cc: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>fbdev: Distinguish between interlaced and progressive modes</title>
<updated>2018-09-26T06:35:06+00:00</updated>
<author>
<name>Fredrik Noring</name>
<email>noring@nocrew.org</email>
</author>
<published>2018-07-24T17:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57a1dd74441dc0c0ff5f0968138f4d82e556c80f'/>
<id>urn:sha1:57a1dd74441dc0c0ff5f0968138f4d82e556c80f</id>
<content type='text'>
[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

    }, {
        /* 1080if */
        "1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
        FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
    }, {
        /* 1080pf */
        "1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
        FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
    },

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring &lt;noring@nocrew.org&gt;
Cc: "Maciej W. Rozycki" &lt;macro@linux-mips.org&gt;
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fbdev/via: fix defined but not used warning</title>
<updated>2018-09-26T06:35:05+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2018-07-24T17:11:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5a85c8d629cbd5731c9eda6cc1a7c041d027683f'/>
<id>urn:sha1:5a85c8d629cbd5731c9eda6cc1a7c041d027683f</id>
<content type='text'>
[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Signed-off-by: Bartlomiej Zolnierkiewicz &lt;b.zolnierkie@samsung.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
