linux-stable.git/drivers, branch v4.9.19

fbcon: Fix vc attr at deinit

2017-03-30T07:41:28+00:00

commit 8aac7f34369726d1a158788ae8aff3002d5eb528 upstream.

fbcon can deal with vc_hi_font_mask (the upper 256 chars) and adjust
the vc attrs dynamically when vc_hi_font_mask is changed at
fbcon_init().  When the vc_hi_font_mask is set, it remaps the attrs in
the existing console buffer with one bit shift up (for 9 bits), while
it remaps with one bit shift down (for 8 bits) when the value is
cleared.  It works fine as long as the font gets updated after fbcon
was initialized.

However, we hit a bizarre problem when the console is switched to
another fb driver (typically from vesafb or efifb to drmfb).  At
switching to the new fb driver, we temporarily rebind the console to
the dummy console, then rebind to the new driver.  During the
switching, we leave the modified attrs as is.  Thus, the new fbcon
takes over the old buffer as if it were to contain 8 bits chars
(although the attrs are still shifted for 9 bits), and effectively
this results in the yellow color texts instead of the original white
color, as found in the bugzilla entry below.

An easy fix for this is to re-adjust the attrs before leaving the
fbcon at con_deinit callback.  Since the code to adjust the attrs is
already present in the current fbcon code, in this patch, we simply
factor out the relevant code, and call it from fbcon_deinit().

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1000619
Signed-off-by: Takashi Iwai 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

drm: reference count event->completion

2017-03-30T07:41:28+00:00

commit 24835e442f289813aa568d142a755672a740503c upstream.

When writing the generic nonblocking commit code I assumed that
through clever lifetime management I can assure that the completion
(stored in drm_crtc_commit) only gets freed after it is completed. And
that worked.

I also wanted to make nonblocking helpers resilient against driver
bugs, by having timeouts everywhere. And that worked too.

Unfortunately taking boths things together results in oopses :( Well,
at least sometimes: What seems to happen is that the drm event hangs
around forever stuck in limbo land. The nonblocking helpers eventually
time out, move on and release it. Now the bug I tested all this
against is drivers that just entirely fail to deliver the vblank
events like they should, and in those cases the event is simply
leaked. But what seems to happen, at least sometimes, on i915 is that
the event is set up correctly, but somohow the vblank fails to fire in
time. Which means the event isn't leaked, it's still there waiting for
eventually a vblank to fire. That tends to happen when re-enabling the
pipe, and then the trap springs and the kernel oopses.

The correct fix here is simply to refcount the crtc commit to make
sure that the event sticks around even for drivers which only
sometimes fail to deliver vblanks for some arbitrary reasons. Since
crtc commits are already refcounted that's easy to do.

References: https://bugs.freedesktop.org/show_bug.cgi?id=96781
Cc: Jim Rees 
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20161221102331.31033-1-daniel.vetter@ffwll.ch
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

drm/bridge: analogix dp: Fix runtime PM state on driver bind

2017-03-30T07:41:28+00:00

commit f0a8b49c03d22a511a601dc54b2a3425a41e35fa upstream.

Analogix_dp_bind() can be called from component framework, which doesn't
guarantee proper runtime PM state of the device during bind operation,
so ensure that device is runtime active before doing any register access.
This ensures that the power domain, to which DP module belongs, is turned
on. While at it, also fix the unbalanced call to phy_power_on() in
analogix_dp_bind() function.

This patch solves the following kernel oops on Samsung Exynos5250 Snow
board:

Unhandled fault: imprecise external abort (0x406) at 0x00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: : 406 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 75 Comm: kworker/0:2 Not tainted 4.9.0 #1046
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
task: ee272300 task.stack: ee312000
PC is at analogix_dp_enable_sw_function+0x18/0x2c
LR is at analogix_dp_init_dp+0x2c/0x50
...
[] (analogix_dp_enable_sw_function) from [] (analogix_dp_init_dp+0x2c/0x50)
[] (analogix_dp_init_dp) from [] (analogix_dp_bind+0x184/0x42c)
[] (analogix_dp_bind) from [] (component_bind_all+0xf0/0x218)
[] (component_bind_all) from [] (exynos_drm_load+0x134/0x200)
[] (exynos_drm_load) from [] (drm_dev_register+0xa0/0xd0)
[] (drm_dev_register) from [] (drm_platform_init+0x58/0xb0)
[] (drm_platform_init) from [] (try_to_bring_up_master+0x14c/0x188)
[] (try_to_bring_up_master) from [] (component_add+0x88/0x138)
[] (component_add) from [] (platform_drv_probe+0x50/0xb0)
[] (platform_drv_probe) from [] (driver_probe_device+0x1f0/0x2a8)
[] (driver_probe_device) from [] (bus_for_each_drv+0x44/0x8c)
[] (bus_for_each_drv) from [] (__device_attach+0x9c/0x100)
[] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
[] (bus_probe_device) from [] (deferred_probe_work_func+0x60/0x8c)
[] (deferred_probe_work_func) from [] (process_one_work+0x120/0x318)
[] (process_one_work) from [] (process_scheduled_works+0x28/0x38)
[] (process_scheduled_works) from [] (worker_thread+0x204/0x4ac)
[] (worker_thread) from [] (kthread+0xd8/0xf4)
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
Code: e59035f0 e5935018 f57ff04f e3c55001 (f57ff04e)
---[ end trace 3d1d0d87796de344 ]---

Reviewed-by: Sean Paul 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Archit Taneja 
Link: http://patchwork.freedesktop.org/patch/msgid/1483091866-1088-1-git-send-email-m.szyprowski@samsung.com
Cc: Javier Martinez Canillas 
Signed-off-by: Greg Kroah-Hartman

device-dax: fix pmd/pte fault fallback handling

2017-03-30T07:41:27+00:00

commit 0134ed4fb9e78672ee9f7b18007114404c81e63f upstream.

Jeff Moyer reports:

    With a device dax alignment of 4KB or 2MB, I get sigbus when running
    the attached fio job file for the current kernel (4.11.0-rc1+).  If
    I specify an alignment of 1GB, it works.

    I turned on debug output, and saw that it was failing in the huge
    fault code.

     dax dax1.0: dax_open
     dax dax1.0: dax_mmap
     dax dax1.0: dax_dev_huge_fault: fio: write (0x7f08f0a00000 -
     dax dax1.0: __dax_dev_pud_fault: phys_to_pgoff(0xffffffffcf60
     dax dax1.0: dax_release

    fio config for reproduce:
    [global]
    ioengine=dev-dax
    direct=0
    filename=/dev/dax0.0
    bs=2m

    [write]
    rw=write

    [read]
    stonewall
    rw=read

The driver fails to fallback when taking a fault that is larger than
the device alignment, or handling a larger fault when a smaller
mapping is already established. While we could support larger
mappings for a device with a smaller alignment, that change is
too large for the immediate fix. The simplest change is to force
fallback until the fault size matches the alignment.

Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Cc: 
Reported-by: Jeff Moyer 
Signed-off-by: Dave Jiang 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Don't leak memory when a channel is rescinded

2017-03-30T07:41:27+00:00

commit 5e030d5ce9d99a899b648413139ff65bab12b038 upstream.

When we close a channel that has been rescinded, we will leak memory since
vmbus_teardown_gpadl() returns an error. Fix this so that we can properly
cleanup the memory allocated to the ring buffers.

Fixes: ccb61f8a99e6 ("Drivers: hv: vmbus: Fix a rescind handling bug")

Signed-off-by: K. Y. Srinivasan 
Cc: Dexuan Cui 
Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Don't leak channel ids

2017-03-30T07:41:27+00:00

commit 9a5476020a5f06a0fc6f17097efc80275d2f03cd upstream.

If we cannot allocate memory for the channel, free the relid
associated with the channel.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

intel_th: Don't leak module refcount on failure to activate

2017-03-30T07:41:27+00:00

commit e609ccef5222c73b46b322be7d3796d60bff353d upstream.

Output 'activation' may fail for the reasons of the output driver,
for example, if msc's buffer is not allocated. We forget, however,
to drop the module reference in this case. So each attempt at
activation in this case leaks a reference, preventing the module
from ever unloading.

This patch adds the missing module_put() in the activation error
path.

Signed-off-by: Alexander Shishkin 
Signed-off-by: Greg Kroah-Hartman

auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches

2017-03-30T07:41:27+00:00

commit abda288bb207e5c681306299126af8c022709c18 upstream.

The OF device table must be terminated, otherwise we'll be walking past it
and into areas unknown.

Fixes: 0cad855fbd08 ("auxdisplay: img-ascii-lcd: driver for simple ASCII...")
Signed-off-by: Dmitry Torokhov 
Tested-by: Fengguang Wu 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: reinstate oland workaround for sclk

2017-03-30T07:41:27+00:00

commit e11ddff68a7c455e63c4b46154a3e75c699a7b55 upstream.

Higher sclks seem to be unstable on some boards.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Restore policy min/max limits on CPU online

2017-03-30T07:41:27+00:00

commit ff010472fb75670cb5c08671e820eeea3af59c87 upstream.

On CPU online the cpufreq core restores the previous governor (or
the previous "policy" setting for ->setpolicy drivers), but it does
not restore the min/max limits at the same time, which is confusing,
inconsistent and real pain for users who set the limits and then
suspend/resume the system (using full suspend), in which case the
limits are reset on all CPUs except for the boot one.

Fix this by making cpufreq_online() restore the limits when an inactive
policy is brought online.

The commit log and patch are inspired from Rafael's earlier work.

Reported-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman