linux-toradex.git/drivers/video, branch toradex_vf_4.1 Linux kernel for Apalis and Colibri modules Merge tag 'v4.1.39' into toradex_vf_4.1-next 2017-03-15T17:35:51+00:00 Stefan Agner stefan@agner.ch 2017-03-14T20:59:28+00:00 39ac0033f2345ce7b5d8ca4439192407dacb2355 Linux 4.1.39 
Linux 4.1.39
Merge tag 'v4.1.32' into toradex_vf_4.1-next 2017-03-15T17:35:47+00:00 Stefan Agner stefan@agner.ch 2016-09-16T20:17:38+00:00 6819e8267b359913b95ccc822ac267454f39a460 Linux 4.1.32 
Linux 4.1.32
fbdev: color map copying bounds checking 2017-03-06T22:31:11+00:00 Kees Cook keescook@chromium.org 2017-01-24T23:18:24+00:00 a94f76f379dcc375f00d32194954f6c4dd1644c9 [ Upstream commit 2dc705a9930b4806250fbf5a76e55266e59389f2 ] Copying color maps to userspace doesn't check the value of to->start, which will cause kernel heap buffer OOB read due to signedness wraps. CVE-2016-8405 Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Peter Pi (@heisecode) of Trend Micro Cc: Min Chong <mchong@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin@verizon.com> 
[ Upstream commit 2dc705a9930b4806250fbf5a76e55266e59389f2 ]

Copying color maps to userspace doesn't check the value of to->start,
which will cause kernel heap buffer OOB read due to signedness wraps.

CVE-2016-8405

Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Peter Pi (@heisecode) of Trend Micro
Cc: Min Chong <mchong@google.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
fbdev: da8xx-fb: fix videomodes of lcd panels 2016-07-11T03:07:12+00:00 Sushaanth Srirangapathi sushaanth.s@ti.com 2016-02-29T13:12:19+00:00 a5e1649e0c4382a0994e91d958ffa70aa11ac226 [ Upstream commit 713fced8d10fa1c759c8fb6bf9aaa681bae68cad ] Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but forgot to update known_lcd_panels[] which had sync values according to old logic. This breaks LCD at least on DA850 EVM. This patch fixes this issue and I have tested this for panel "Sharp_LK043T1DG01" using DA850 EVM board. Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
[ Upstream commit 713fced8d10fa1c759c8fb6bf9aaa681bae68cad ]

Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the
hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but
forgot to update known_lcd_panels[] which had sync values
according to old logic. This breaks LCD at least on DA850 EVM.

This patch fixes this issue and I have tested this for panel
"Sharp_LK043T1DG01" using DA850 EVM board.

Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse")
Signed-off-by: Sushaanth Srirangapathi <sushaanth.s@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
xen kconfig: don't "select INPUT_XEN_KBDDEV_FRONTEND" 2016-07-11T03:07:10+00:00 Arnd Bergmann arnd@arndb.de 2016-02-16T15:03:23+00:00 372574134cc15a03608d87a3577885b049e40db3 [ Upstream commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 ] The Xen framebuffer driver selects the xen keyboard driver, so the latter will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT is a loadable module, this configuration cannot work. On mainline kernels, the symbol will be enabled but not used, while in combination with a patch I have to detect such useless configurations, we get the expected link failure: drivers/input/built-in.o: In function `xenkbd_remove': xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device' xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device' This removes the extra "select", as it just causes more trouble than it helps. In theory, some defconfig file might break if it has XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig fragment we ship in the kernel (kernel/configs/xen.config) however already enables both, and anyone using an old .config file would keep having both enabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: David Vrabel <david.vrabel@citrix.com> Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND") Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> 
[ Upstream commit 13aa38e291bdd4e4018f40dd2f75e464814dcbf3 ]

The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:

drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'

This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
backlight: gpio-backlight: use default-on on GPIO request 2015-10-23T23:20:47+00:00 Stefan Agner stefan.agner@toradex.com 2015-10-23T23:20:47+00:00 74b659a2ad1a0030c47325ea26160afe04e1123b There are situations where the backlight should be on at boot time (e.g. if the boot loader already turned the display on). The DT bindings specify the "default-on" property for that purpose. Currently, the initial state of the GPIO at request time is always set to logical off (high or low depending on whether it is an active high or low GPIO). Since the GPIO is requested as an output, the GPIO will be driven low for a short period of time, which leads to a flickering display in the above use-case. Initialize the GPIO depending on the default-on property to be logical on or off. 
There are situations where the backlight should be on at boot time
(e.g. if the boot loader already turned the display on). The DT
bindings specify the "default-on" property for that purpose.
Currently, the initial state of the GPIO at request time is always
set to logical off (high or low depending on whether it is an
active high or low GPIO). Since the GPIO is requested as an output,
the GPIO will be driven low for a short period of time, which leads
to a flickering display in the above use-case.

Initialize the GPIO depending on the default-on property to be
logical on or off.
Merge tag 'v4.1.11' into toradex_vf_4.1-next 2015-10-23T22:25:54+00:00 Stefan Agner stefan.agner@toradex.com 2015-10-23T22:25:54+00:00 0df341edfa5e7c119523a0c30146e88106f88b43 This is the 4.1.11 stable release 
This is the 4.1.11 stable release
fbdev: select versatile helpers for the integrator 2015-10-22T21:43:20+00:00 Linus Walleij linus.walleij@linaro.org 2015-07-28T13:31:12+00:00 1fc6fc1d5b9dc9c878b2b1c044e079b193e6cb92 commit 2701fa0864ecb9e49d47a4aa1c02f172ab79639a upstream. Commit 11c32d7b6274cb0f554943d65bd4a126c4a86dcd "video: move Versatile CLCD helpers" missed the fact that the Integrator/CP is also using the helper, and as a result the platform got only stubs and no graphics. Add this as a default selection to Kconfig so we have graphics again. Fixes: 11c32d7b6274 (video: move Versatile CLCD helpers) Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2701fa0864ecb9e49d47a4aa1c02f172ab79639a upstream.

Commit 11c32d7b6274cb0f554943d65bd4a126c4a86dcd
"video: move Versatile CLCD helpers" missed the fact
that the Integrator/CP is also using the helper, and
as a result the platform got only stubs and no graphics.
Add this as a default selection to Kconfig so we have
graphics again.

Fixes: 11c32d7b6274 (video: move Versatile CLCD helpers)
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fbcon: logo: allow easy integration of a custom Linux boot logo 2015-09-21T06:42:12+00:00 Marcel Ziswiler marcel.ziswiler@toradex.com 2013-01-25T15:10:50+00:00 b4040c3816907f203d9fa7d3d24568e98c076848 This patch allows for easy integration of a custom Linux boot logo to replace the Tux' being shown by default. Use gimp or the like to create a raw PPM in your desired resolution. Reduce the number of colours in the image to 224: user@host:~$ ppmquant 224 Toradex-640x480.ppm > \ Toradex-640x480-224.ppm ppmquant: making histogram... ppmquant: 370 colors found ppmquant: choosing 224 colors... ppmquant: mapping image to new colors... Convert it from raw PPM to ASCII format: user@host:~$ pnmnoraw Toradex-640x480-224.ppm > \ Toradex-640x480-ascii-224.ppm Copy it into the Linux sources: cp Toradex-640x480-ascii-224.ppm linux-toradex/drivers/video/logo/\ logo_custom_clut224.ppm Activate exclusively custom Linux logo in the kernel configuration: Device Drivers -> Graphics support -> Bootup logo -> Custom 224-color Linux logo And re-compile the kernel. (cherry picked from commit fa2371bff9ac03581881849d8f95678ef3992719) 
This patch allows for easy integration of a custom Linux boot logo to
replace the Tux' being shown by default.

Use gimp or the like to create a raw PPM in your desired resolution.

Reduce the number of colours in the image to 224:

  user@host:~$ ppmquant 224 Toradex-640x480.ppm > \
    Toradex-640x480-224.ppm
  ppmquant: making histogram...
  ppmquant: 370 colors found
  ppmquant: choosing 224 colors...
  ppmquant: mapping image to new colors...

Convert it from raw PPM to ASCII format:

  user@host:~$ pnmnoraw Toradex-640x480-224.ppm > \
    Toradex-640x480-ascii-224.ppm

Copy it into the Linux sources:

  cp Toradex-640x480-ascii-224.ppm linux-toradex/drivers/video/logo/\
    logo_custom_clut224.ppm

Activate exclusively custom Linux logo in the kernel configuration:

  Device Drivers -> Graphics support -> Bootup logo ->
    Custom 224-color Linux logo

And re-compile the kernel.

(cherry picked from commit fa2371bff9ac03581881849d8f95678ef3992719)
Merge branch 'vf610-dcu-4.1' into toradex_vf_4.1-next 2015-08-13T13:00:41+00:00 Stefan Agner stefan.agner@toradex.com 2015-08-13T13:00:41+00:00 4d054fbf42d98a54bdb330eebfe419af8a825118