user/sven/linux.git/drivers/video, branch v3.4.85

video: kyro: fix incorrect sizes when copying to userspace

2013-12-08T15:29:43Z

commit 2ab68ec927310dc488f3403bb48f9e4ad00a9491 upstream. kyro would copy u32s and specify sizeof(unsigned long) as the size to copy. This would copy more data than intended and cause memory corruption and might leak kernel memory. Signed-off-by: Sasha Levin Signed-off-by: Tomi Valkeinen Signed-off-by: Greg Kroah-Hartman

backlight: atmel-pwm-bl: fix reported brightness

2013-12-04T18:50:13Z

commit 185d91442550110db67a7dc794a32efcea455a36 upstream. The driver supports 16-bit brightness values, but the value returned from get_brightness was truncated to eight bits. Signed-off-by: Johan Hovold Cc: Jingoo Han Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Fix a few incorrectly checked [io_]remap_pfn_range() calls

2013-11-29T18:50:32Z

commit 7314e613d5ff9f0934f7a0f74ed7973b903315d1 upstream. Nico Golde reports a few straggling uses of [io_]remap_pfn_range() that really should use the vm_iomap_memory() helper. This trivially converts two of them to the helper, and comments about why the third one really needs to continue to use remap_pfn_range(), and adds the missing size check. Reported-by: Nico Golde Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fbcon: when font is freed, clear also vc_font.data

2013-05-08T02:51:53Z

commit e6637d5427d2af9f3f33b95447bfc5347e5ccd85 upstream. commit ae1287865f5361fa138d4d3b1b6277908b54eac9 Author: Dave Airlie Date: Thu Jan 24 16:12:41 2013 +1000 fbcon: don't lose the console font across generic->chip driver switch uses a pointer in vc->vc_font.data to load font into the new driver. However if the font is actually freed, we need to clear the data so that we don't reload font from dangling pointer. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340 Signed-off-by: Mika Kuoppala Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

vm: convert fb_mmap to vm_iomap_memory() helper

2013-04-26T04:19:56Z

commit fc9bbca8f650e5f738af8806317c0a041a48ae4a upstream. This is my example conversion of a few existing mmap users. The fb_mmap() case is a good example because it is a bit more complicated than some: fb_mmap() mmaps one of two different memory areas depending on the page offset of the mmap (but happily there is never any mixing of the two, so the helper function still works). Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fbcon: fix locking harder

2013-04-26T04:19:56Z

commit 054430e773c9a1e26f38e30156eff02dedfffc17 upstream. Okay so Alan's patch handled the case where there was no registered fbcon, however the other path entered in set_con2fb_map pit. In there we called fbcon_takeover, but we also took the console lock in a couple of places. So push the console lock out to the callers of set_con2fb_map, this means fbmem and switcheroo needed to take the lock around the fb notifier entry points that lead to this. This should fix the efifb regression seen by Maarten. Tested-by: Maarten Lankhorst Tested-by: Lu Hua Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

atmel_lcdfb: fix 16-bpp modes on older SOCs

2013-03-20T20:05:00Z

commit a79eac7165ed62114e6ca197195aa5060a54f137 upstream. Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp modes for older SOCs which use IBGR:555 (msb is intensity) rather than BGR:565. Use SOC-type to determine the pixel layout. Tested on at91sam9263 and at91sam9g45. Acked-by: Peter Korsgaard Signed-off-by: Johan Hovold Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

fb: Yet another band-aid for fixing lockdep mess

2013-02-28T14:59:05Z

commit e93a9a868792ad71cdd09d75e5a02d8067473c4e upstream. I've still got lockdep warnings even after Alan's patch, and it seems that yet more band aids are required to paper over similar paths for unbind_con_driver() and unregister_con_driver(). After this hack, lockdep warnings are finally gone. Signed-off-by: Takashi Iwai Cc: Alan Cox Cc: Florian Tobias Schandinat Cc: Jiri Kosina Tested-by: Sedat Dilek Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

fb: rework locking to fix lock ordering on takeover

2013-02-28T14:59:05Z

commit 50e244cc793d511b86adea24972f3a7264cae114 upstream. Adjust the console layer to allow a take over call where the caller already holds the locks. Make the fb layer lock in order. This is partly a band aid, the fb layer is terminally confused about the locking rules it uses for its notifiers it seems. [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment] [akpm@linux-foundation.org: export do_take_over_console()] [airlied: cleanup another non-ascii char] Signed-off-by: Alan Cox Cc: Florian Tobias Schandinat Cc: Stephen Rothwell Cc: Jiri Kosina Tested-by: Sedat Dilek Reviewed-by: Daniel Vetter Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

fbcon: don't lose the console font across generic->chip driver switch

2013-02-28T14:59:05Z

commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream. If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code is doing the right thing, it frees the font because otherwise it would leak memory. However we can assume that if you are removing the generic firmware driver (vesa/efi/offb), that a new driver *should* be loading soon after, so we effectively leak the font. However the old code left a dangling pointer in vc->vc_font.data and we can now reuse that dangling pointer to load the font into the new driver, now that we aren't freeing it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340 Signed-off-by: Dave Airlie Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman