linux-stable.git/drivers/video, branch v3.12.18

fbdev: Make the switch from generic to native driver less alarming

2014-04-18T09:04:16+00:00

commit 13ba0ad4490c3dd08b15c430a7a01c6fb45d5bce upstream.

Calling this "conflicting" just makes people think there's a problem
when there's not.

Signed-off-by: Adam Jackson 
Reviewed-by: David Herrmann 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

video/fb: Propagate error code from failing to unregister conflicting fb

2014-04-18T09:03:59+00:00

commit 46eeb2c144956e88197439b5ee5cf221a91b0a81 upstream.

If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.

Signed-off-by: Chris Wilson 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Jani Nikula 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

fb: reorder the lock sequence to fix potential dead lock

2014-04-18T09:03:37+00:00

commit 3a41c5dbe8bc396a7fb16ca8739e945bb003342e upstream.

Following commits:

50e244cc79 fb: rework locking to fix lock ordering on takeover
e93a9a8687 fb: Yet another band-aid for fixing lockdep mess
054430e773 fbcon: fix locking harder

reworked locking to fix related lock ordering on takeover, and introduced console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
a potential dead lock as following:

[  601.079000] ======================================================
[  601.079000] [ INFO: possible circular locking dependency detected ]
[  601.079000] 3.11.0 #189 Not tainted
[  601.079000] -------------------------------------------------------
[  601.079000] kworker/0:3/619 is trying to acquire lock:
[  601.079000]  (&fb_info->lock){+.+.+.}, at: [] lock_fb_info+0x26/0x60
[  601.079000]
but task is already holding lock:
[  601.079000]  (console_lock){+.+.+.}, at: [] console_callback+0x13/0x160
[  601.079000]
which lock already depends on the new lock.

[  601.079000]
the existing dependency chain (in reverse order) is:
[  601.079000]
-> #1 (console_lock){+.+.+.}:
[  601.079000]        [] lock_acquire+0xa1/0x140
[  601.079000]        [] console_lock+0x77/0x80
[  601.079000]        [] register_framebuffer+0x1d8/0x320
[  601.079000]        [] efifb_probe+0x408/0x48f
[  601.079000]        [] platform_drv_probe+0x43/0x80
[  601.079000]        [] driver_probe_device+0x8b/0x390
[  601.079000]        [] __driver_attach+0xab/0xb0
[  601.079000]        [] bus_for_each_dev+0x5d/0xa0
[  601.079000]        [] driver_attach+0x1e/0x20
[  601.079000]        [] bus_add_driver+0x117/0x290
[  601.079000]        [] driver_register+0x7a/0x170
[  601.079000]        [] __platform_driver_register+0x4a/0x50
[  601.079000]        [] platform_driver_probe+0x1d/0xb0
[  601.079000]        [] efifb_init+0x273/0x292
[  601.079000]        [] do_one_initcall+0x102/0x1c0
[  601.079000]        [] kernel_init_freeable+0x15d/0x1ef
[  601.079000]        [] kernel_init+0xe/0xf0
[  601.079000]        [] ret_from_fork+0x7c/0xb0
[  601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[  601.079000]        [] __lock_acquire+0x1e18/0x1f10
[  601.079000]        [] lock_acquire+0xa1/0x140
[  601.079000]        [] mutex_lock_nested+0x7a/0x3b0
[  601.079000]        [] lock_fb_info+0x26/0x60
[  601.079000]        [] fbcon_blank+0x29b/0x2e0
[  601.079000]        [] do_blank_screen+0x1d8/0x280
[  601.079000]        [] console_callback+0x64/0x160
[  601.079000]        [] process_one_work+0x1f5/0x540
[  601.079000]        [] worker_thread+0x11c/0x370
[  601.079000]        [] kthread+0xed/0x100
[  601.079000]        [] ret_from_fork+0x7c/0xb0
[  601.079000]
other info that might help us debug this:

[  601.079000]  Possible unsafe locking scenario:

[  601.079000]        CPU0                    CPU1
[  601.079000]        ----                    ----
[  601.079000]   lock(console_lock);
[  601.079000]                                lock(&fb_info->lock);
[  601.079000]                                lock(console_lock);
[  601.079000]   lock(&fb_info->lock);
[  601.079000]
 *** DEADLOCK ***

so we reorder the lock sequence the same as it in console_callback() to
avoid this issue. And following Tomi's suggestion, fix these similar
issues all in fb subsystem.

Signed-off-by: Gu Zheng 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

fbmem: really support wildcard video=options for all fbdev drivers

2014-04-03T08:32:12+00:00

commit f5d2b7c28b67d627646b6a0142bc201a7b1516b0 upstream.

Documentation/fb/modedb.txt states that video=option should be
considered a global option. But video_setup and fb_get_options are not
coded that way. Instead its required to boot with video=driver:option to
set a given option in drvier.  This is cumbersome because it requires to
know in advance which driver will be active for a given board/kernel.

The following patch implements the documented catchall for the fbdev
drivers. It is now possible to boot with video=XxY without the need to
know the active driver in advance. The specific case it tries to fix is
syslinux in the SUSE installer which offers a menu to set a display
resolution. Right now this just appends the vga= option the kernel. But
in addition to vga= it should be possible to pass a generic video=XxY
for all framebuffer/drm drivers. With this change forcing a certain
window size of VM displays is now much easier.

Today the video= option is stored in a global fb_mode_option. But
unfortunately only drm uses it.

Note: this change introduces a small memleak if video=option is actually
used because fb_mode_option is const. Most drivers use strsep to get to
individual options. This could be fixed in a followup patch which always
releases the option string in every caller of fb_get_options.

Signed-off-by: Olaf Hering 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

efifb: prevent null-deref when iterating dmi_list

2014-03-12T12:25:34+00:00

commit 55aa42f2e690157e254a6a6989f5f4ac928b35c8 upstream.

The dmi_list array is initialized using gnu designated initializers, and
therefore may contain fewer explicitly defined entries as there are
elements in it. This is because the enum above with M_xyz constants
contains more items than the designated initializer. Those elements not
explicitly initialized are implicitly set to 0.

Now efifb_setup() loops through all these array elements, and performs
a strcmp on each item. For non explicitly initialized elements this will
be a null pointer:

This patch swaps the check order in the if statement, thus checks first
whether dmi_list[i].base is null.

Signed-off-by: James Bates 
Signed-off-by: David Herrmann 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Jiri Slaby

xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).

2014-02-13T21:50:10+00:00

commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream.

The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)

which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:

  xen_platform_pci=0
  (in the guest config file)

or
  xen_emul_unplug=never
  (on the Linux command line)

except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:

input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[]  [] get_free_entries+0x2e0/0x300
Call Trace:
 [] ? evdev_connect+0x1e3/0x240
 [] gnttab_grant_foreign_access+0x2e/0x70
 [] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
 [] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
 [] xenbus_dev_probe+0x77/0x130
 [] xenbus_frontend_dev_probe+0x47/0x50
 [] driver_probe_device+0x89/0x230
 [] __driver_attach+0x9b/0xa0
 [] ? driver_probe_device+0x230/0x230
 [] ? driver_probe_device+0x230/0x230
 [] bus_for_each_dev+0x8c/0xb0
 [] driver_attach+0x19/0x20
 [] bus_add_driver+0x1a0/0x220
 [] driver_register+0x5f/0xf0
 [] xenbus_register_driver_common+0x15/0x20
 [] xenbus_register_frontend+0x23/0x40
 [] ? 0xffffffffa0014fff
 [] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
 [] do_one_initcall+0x49/0x170

.. snip..

which is hardly nice. This patch fixes this by having each
PV driver check for:
 - if running in PV, then it is fine to execute (as that is their
   native environment).
 - if running in HVM, check if user wanted 'xen_emul_unplug=never',
   in which case bail out and don't load any PV drivers.
 - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
   does not exist, then bail out and not load PV drivers.
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
   then bail out for all PV devices _except_ the block one.
   Ditto for the network one ('nics').
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
   then load block PV driver, and also setup the legacy IDE paths.
   In (v3) make it actually load PV drivers.

Reported-by: Sander Eikelenboom 
Reported-and-Tested-by: Fabio Fantoni 
Signed-off-by: Konrad Rzeszutek Wilk 
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
[v4: s/disks/ide-disks/ spotted by Fabio]
Reviewed-by: Stefano Stabellini 
Acked-by: Bjorn Helgaas  [for PCI parts]
Signed-off-by: Greg Kroah-Hartman

ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance

2013-12-12T06:37:52+00:00

commit c37dd677988ca50bc8bc60ab5ab053720583c168 upstream.

When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig
(LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled,
the following BUG is seen during the boot:

[    7.302154] =====================================
[    7.307128] [ BUG: bad unlock balance detected! ]
[    7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7 #3 Not tainted
[    7.318450] -------------------------------------
[    7.323425] kworker/u2:1/12 is trying to release lock (&ddata->mutex) at:
[    7.330657] [] acx565akm_enable+0x12c/0x18c
[    7.335998] but there are no more locks to release!

Fix by removing double unlock and handling the locking completely inside
acx565akm_panel_power_on() when doing the power on.

Reported-by: Eduardo Valentin 
Signed-off-by: Aaro Koskinen 
Signed-off-by: Tomi Valkeinen 
Signed-off-by: Greg Kroah-Hartman

video: kyro: fix incorrect sizes when copying to userspace

2013-12-08T15:29:16+00:00

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-04T19:05:08+00:00

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

backlight: atmel-pwm-bl: fix gpio polarity in remove

2013-12-04T19:05:08+00:00

commit ad5066d4c2b1d696749f8d7816357c23b648c4d3 upstream.

Make sure to honour gpio polarity also at remove so that the backlight is
actually disabled on boards with active-low enable pin.

Signed-off-by: Johan Hovold 
Acked-by: Jingoo Han 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman