linux-stable.git/drivers/video/fbdev, branch v4.9.166

fbdev: fbmem: behave better with small rotated displays and many CPUs

2019-02-12T18:44:56+00:00

[ Upstream commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 ]

Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW). There is however no protection when drawing in the
opposite directions (ROTATE_UD and ROTATE_CCW).

Add back this protection.

The regression is 20-odd years old but the mindless warning-killing
mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove
positive test on unsigned values") is also to blame, methinks.

Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates")
Signed-off-by: Peter Rosin 
Cc: Tomi Valkeinen 
Cc: Fabian Frederick 
Cc: Geert Uytterhoeven 
cc: Geoff Levand 
Cc: James Simmons 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin

video: clps711x-fb: release disp device node in probe()

2019-02-12T18:44:56+00:00

[ Upstream commit fdac751355cd76e049f628afe6acb8ff4b1399f7 ]

clps711x_fb_probe() increments refcnt of disp device node by
of_parse_phandle() and leaves it undecremented on both
successful and error paths.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
Cc: Alexander Shiyan 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin

omap2fb: Fix stack memory disclosure

2019-01-23T07:10:55+00:00

commit a01421e4484327fe44f8e126793ed5a48a221e24 upstream.

Using [1] for static analysis I found that the OMAPFB_QUERY_PLANE,
OMAPFB_GET_COLOR_KEY, OMAPFB_GET_DISPLAY_INFO, and OMAPFB_GET_VRAM_INFO
cases could all leak uninitialized stack memory--either due to
uninitialized padding or 'reserved' fields.

Fix them by clearing the shared union used to store copied out data.

[1] https://github.com/vlad902/kernel-uninitialized-memory-checker

Signed-off-by: Vlad Tsyrklevich 
Reviewed-by: Kees Cook 
Fixes: b39a982ddecf ("OMAP: DSS2: omapfb driver")
Cc: security@kernel.org
[b.zolnierkie: prefix patch subject with "omap2fb: "]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman

mach64: fix image corruption due to reading accelerator registers

2018-11-21T08:26:00+00:00

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 
Reviewed-by: Ville Syrjälä 
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman

mach64: fix display corruption on big endian machines

2018-11-21T08:25:59+00:00

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->depth). If we want to blit full-color image, we
shouldn't use the triple code.

Signed-off-by: Mikulas Patocka 
Reviewed-by: Ville Syrjälä 
Cc: stable@vger.kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman

efi/fb: Correct PCI_STD_RESOURCE_END usage

2018-11-10T15:42:45+00:00

[ Upstream commit 92a16c86299c64f58f320e491977408ba31b8c3c ]

PCI_STD_RESOURCE_END is (confusingly) the index of the last valid BAR, not
the *number* of BARs.  To iterate through all possible BARs, we need to
include PCI_STD_RESOURCE_END.

Fixes: 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that covers the framebuffer")
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin

pxa168fb: prepare the clock

2018-11-10T15:42:43+00:00

[ Upstream commit d85536cde91fcfed6fb8d983783bd2b92c843939 ]

Add missing prepare/unprepare operations for fbi->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)
  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
  [] (show_stack) from [] (__warn+0xd8/0xf0)
  [] (__warn) from [] (warn_slowpath_fmt+0x44/0x6c)
  [] (warn_slowpath_fmt) from [] (clk_core_enable+0x2c/0x1b0)
  [] (clk_core_enable) from [] (clk_core_enable_lock+0x18/0x2c)
  [] (clk_core_enable_lock) from [] (pxa168fb_probe+0x464/0x6ac)
  [] (pxa168fb_probe) from [] (platform_drv_probe+0x48/0x94)
  [] (platform_drv_probe) from [] (driver_probe_device+0x328/0x470)
  [] (driver_probe_device) from [] (__driver_attach+0xb0/0x124)
  [] (__driver_attach) from [] (bus_for_each_dev+0x64/0xa0)
  [] (bus_for_each_dev) from [] (bus_add_driver+0x1b8/0x230)
  [] (bus_add_driver) from [] (driver_register+0xac/0xf0)
  [] (driver_register) from [] (do_one_initcall+0xb8/0x1f0)
  [] (do_one_initcall) from [] (kernel_init_freeable+0x294/0x2e0)
  [] (kernel_init_freeable) from [] (kernel_init+0x8/0x10c)
  [] (kernel_init) from [] (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 
[b.zolnierkie: enhance patch description a bit]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin

mach64: detect the dot clock divider correctly on sparc

2018-10-18T07:13:21+00:00

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 
Cc: stable@vger.kernel.org
Acked-by: David S. Miller 
Reviewed-by: Ville Syrjälä 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

fbdev/omapfb: fix omapfb_memory_read infoleak

2018-10-13T07:18:53+00:00

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 & height parameters, and only copying
the amount of data that we actually received from the LCD.

Signed-off-by: Tomi Valkeinen 
Reported-by: Jann Horn 
Cc: stable@vger.kernel.org
Cc: security@kernel.org
Cc: Will Deacon 
Cc: Jann Horn 
Cc: Tony Lindgren 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Greg Kroah-Hartman

fbdev: Distinguish between interlaced and progressive modes

2018-09-26T06:36:32+00:00

[ 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 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman