linux-stable.git/drivers, branch v3.18.34

drm/i915: Bail out of pipe config compute loop on LPT

2016-05-18T01:56:40+00:00

[ Upstream commit 2700818ac9f935d8590715eecd7e8cadbca552b6 ]

LPT is pch, so might run into the fdi bandwidth constraint (especially
since it has only 2 lanes). But right now we just force pipe_bpp back
to 24, resulting in a nice loop (which we bail out with a loud
WARN_ON). Fix this.

Cc: Chris Wilson 
Cc: Maarten Lankhorst 
References: https://bugs.freedesktop.org/show_bug.cgi?id=93477
Signed-off-by: Daniel Vetter 
Tested-by: Chris Wilson 
Signed-off-by: Maarten Lankhorst 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1462264381-7573-1-git-send-email-daniel.vetter@ffwll.ch
(cherry picked from commit f58a1acc7e4a1f37d26124ce4c875c647fbcc61f)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

Input: max8997-haptic - fix NULL pointer dereference

2016-05-18T01:56:34+00:00

[ Upstream commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 ]

NULL pointer derefence happens when booting with DTB because the
platform data for haptic device is not set in supplied data from parent
MFD device.

The MFD device creates only platform data (from Device Tree) for itself,
not for haptic child.

Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
	[0000009c] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	(max8997_haptic_probe) from [] (platform_drv_probe+0x4c/0xb0)
	(platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0)
	(driver_probe_device) from [] (__driver_attach+0xac/0xb0)
	(__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
	(bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
	(bus_add_driver) from [] (driver_register+0x78/0xf8)
	(driver_register) from [] (do_one_initcall+0x90/0x1d8)
	(do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc)
	(kernel_init_freeable) from [] (kernel_init+0x8/0x114)
	(kernel_init) from [] (ret_from_fork+0x14/0x3c)

Signed-off-by: Marek Szyprowski 
Cc: 
Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Dmitry Torokhov 

Signed-off-by: Sasha Levin

ACPICA: Dispatcher: Update thread ID for recursive method calls

2016-05-17T21:30:14+00:00

[ Upstream commit 93d68841a23a5779cef6fb9aa0ef32e7c5bd00da ]

ACPICA commit 7a3bd2d962f221809f25ddb826c9e551b916eb25

Set the mutex owner thread ID.
Original patch from: Prarit Bhargava 

Link: https://bugzilla.kernel.org/show_bug.cgi?id=115121
Link: https://github.com/acpica/acpica/commit/7a3bd2d9
Signed-off-by: Prarit Bhargava 
Tested-by: Andy Lutomirski  # On a Dell XPS 13 9350
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

drm/radeon: make sure vertical front porch is at least 1

2016-05-17T21:30:03+00:00

[ Upstream commit 3104b8128d4d646a574ed9d5b17c7d10752cd70b ]

hw doesn't like a 0 value.

Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read()

2016-05-17T21:29:35+00:00

[ Upstream commit 1db488d12894f1936360779d6ab2aede3dd7f06a ]

On the consumer side, we have interrupt driven flow management of the
producer. It is sufficient to base the signaling decision on the
amount of space that is available to write after the read is complete.
The current code samples the previous available space and uses this
in making the signaling decision. This state can be stale and is
unnecessary. Since the state can be stale, we end up not signaling
the host (when we should) and this can result in a hang. Fix this
problem by removing the unnecessary check. I would like to thank
Arseney Romanenko  for pointing out this issue.

Also, issue a full memory barrier before making the signaling descision
to correctly deal with potential reordering of the write (read index)
followed by the read of pending_sz.

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

Drivers: hv_vmbus: Fix signal to host condition

2016-05-17T21:29:26+00:00

[ Upstream commit a5cca686ce0ef4909deaee4ed46dd991e3a9ece4 ]

Fixes a bug where previously hv_ringbuffer_read would pass in the old
number of bytes available to read instead of the expected old read index
when calculating when to signal to the host that the ringbuffer is empty.
Since the previous write size is already saved, also changes the
hv_need_to_signal_on_read to use the previously read value rather than
recalculating it.

Signed-off-by: Christopher Oo 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Drivers: hv: ring_buffer.c: fix comment style

2016-05-17T21:29:19+00:00

[ Upstream commit 822f18d4d3e9d4efb4996bbe562d0f99ab82d7dd ]

Convert 6+-string comments repeating function names to normal kernel-style
comments and fix a couple of other comment style issues. No textual or
functional changes intended.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

EDAC: i7core, sb_edac: Don't return NOTIFY_BAD from mce_decoder callback

2016-05-17T18:52:13+00:00

[ Upstream commit c4fc1956fa31003bfbe4f597e359d751568e2954 ]

Both of these drivers can return NOTIFY_BAD, but this terminates
processing other callbacks that were registered later on the chain.
Since the driver did nothing to log the error it seems wrong to prevent
other interested parties from seeing it. E.g. neither of them had even
bothered to check the type of the error to see if it was a memory error
before the return NOTIFY_BAD.

Signed-off-by: Tony Luck 
Acked-by: Aristeu Rozanski 
Acked-by: Mauro Carvalho Chehab 
Cc: linux-edac 
Cc: 
Link: http://lkml.kernel.org/r/72937355dd92318d2630979666063f8a2853495b.1461864507.git.tony.luck@intel.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Sasha Levin

IB/security: Restrict use of the write() interface

2016-05-17T18:51:48+00:00

[ Upstream commit e6bd18f57aad1a2d1ef40e646d03ed0f2515c9e3 ]

The drivers/infiniband stack uses write() as a replacement for
bi-directional ioctl().  This is not safe. There are ways to
trigger write calls that result in the return structure that
is normally written to user space being shunted off to user
specified kernel memory instead.

For the immediate repair, detect and deny suspicious accesses to
the write API.

For long term, update the user space libraries and the kernel API
to something that doesn't present the same security vulnerabilities
(likely a structured ioctl() interface).

The impacted uAPI interfaces are generally only available if
hardware from drivers/infiniband is installed in the system.

Reported-by: Jann Horn 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jason Gunthorpe 
[ Expanded check to all known write() entry points ]
Cc: stable@vger.kernel.org
Signed-off-by: Doug Ledford 

Signed-off-by: Sasha Levin

drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume

2016-05-17T18:49:16+00:00

[ Upstream commit 5eaa60c7109b40f17ac81090bc8b90482da76cd1 ]

The driver's VDD on/off logic assumes that whenever the VDD is on we
also hold an AUX power domain reference. Since BIOS can leave the VDD on
during booting and resuming and on DDI platforms we won't take a
corresponding power reference, the above assumption won't hold on those
platforms and an eventual delayed VDD off work will do an extraneous AUX
power domain put resulting in a refcount underflow. Fix this the same
way we did this for non-DDI DP encoders:

commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system
resume")

At the same time call the DP encoder suspend handler the same way as the
non-DDI DP encoders do to flush any pending VDD off work. Leaving the
work running may cause a HW access where we don't expect this (at a point
where power domains are suspended already).

While at it remove an unnecessary function call indirection.

This fixed for me AUX refcount underflow problems on BXT during
suspend/resume.

CC: Ville Syrjälä 
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
(cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin