linux.git/drivers, branch v4.11.5

drm/i915/vbt: split out defaults that are set when there is no VBT

2017-06-14T13:07:51+00:00

commit bb1d132935c2f87cd261eb559759fe49d5e5dc43 upstream.

The main thing are the DDI ports. If there's a VBT that says there are
no outputs, we should trust that, and not have semi-random
defaults. Unfortunately, the defaults have resulted in some Chromebooks
without VBT to rely on this behaviour, so we split out the defaults for
the missing VBT case.

Reviewed-by: Manasi Navare 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/95c26079ff640d43f53b944f17e9fc356b36daec.1489152288.git.jani.nikula@intel.com
Signed-off-by: Greg Kroah-Hartman

drm/i915/vbt: don't propagate errors from intel_bios_init()

2017-06-14T13:07:51+00:00

commit 665788572c6410b7efadc2e3009c5d830b6d8ef9 upstream.

We don't use the error return for anything other than reporting and
logging that there is no VBT. We can pull the logging in the function,
and remove the error status return. Moreover, if we needed the
information for something later on, we'd probably be better off storing
the bit in dev_priv, and using it where it's needed, instead of using
the error return.

While at it, improve the comments.

Cc: Manasi Navare 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/438ebbb0d5f0d321c625065b9cc78532a1dab24f.1489152288.git.jani.nikula@intel.com
Signed-off-by: Greg Kroah-Hartman

hwmon: (coretemp) Handle frozen hotplug state correctly

2017-06-14T13:07:51+00:00

commit 90b4f30b6d15222a509dacf47f29efef2b22571e upstream.

The recent conversion to the hotplug state machine missed that the original
hotplug notifiers did not execute in the frozen state, which is used on
suspend on resume.

This does not matter on single socket machines, but on multi socket systems
this breaks when the device for a non-boot socket is removed when the last
CPU of that socket is brought offline. The device removal locks up the
machine hard w/o any debug output.

Prevent executing the hotplug callbacks when cpuhp_tasks_frozen is true.

Thanks to Tommi for providing debug information patiently while I failed to
spot the obvious.

Fixes: e00ca5df37ad ("hwmon: (coretemp) Convert to hotplug state machine")
Reported-by: Tommi Rantala 
Tested-by: Tommi Rantala 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Guenter Roeck 
Cc: "Chen, Yu C" 
Signed-off-by: Greg Kroah-Hartman

pinctrl: cherryview: Add terminate entry for dmi_system_id tables

2017-06-14T13:07:50+00:00

commit a9de080bbcd5c4e213a3d7bbb1e314d60980e943 upstream.

Make sure dmi_system_id tables are NULL terminated.

Fixes: 703650278372 ("pinctrl: cherryview: Add a quirk to make Acer
Chromebook keyboard work again")
Signed-off-by: Wei Yongjun 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Cc: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix panic when serial console and DMA are enabled

2017-06-14T13:07:50+00:00

commit 3c9101766b502a0163d1d437fada5801cf616be2 upstream.

This patch fixes an issue that kernel panic happens when DMA is enabled
and we press enter key while the kernel booting on the serial console.

* An interrupt may occur after sci_request_irq().
* DMA transfer area is initialized by setup_timer() in sci_request_dma()
  and used in interrupt.

If an interrupt occurred between sci_request_irq() and setup_timer() in
sci_request_dma(), DMA transfer area has not been initialized yet.
So, this patch changes the order of sci_request_irq() and
sci_request_dma().

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Takatoshi Akiyama 
[Shimoda changes the commit log]
Signed-off-by: Yoshihiro Shimoda 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix runtime PM for LPE audio

2017-06-14T13:07:50+00:00

commit 668e3b014afb66ab29e134bca7c258527273ac75 upstream.

Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.

Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, otherwise the core gets upset. Also if there's
no LPE audio driver loaded then we couldn't runtime suspend
i915 either.

So it looks like a better plan is to call it from i915 when
we register the platform device. That seems to match how
pci generally does things. I cargo culted the
pm_runtime_forbid() and pm_runtime_set_active() calls from
pci as well.

The exposed runtime PM API is massive an thorougly misleading, so
I don't actually know if this is how you're supposed to use the API
or not. But it seems to work. I can now runtime suspend i915 again
with or without the LPE audio driver loaded, and reloading the
LPE audio driver also seems to work.

Note that powertop won't auto-tune runtime PM for platform devices,
which is a little annoying. So I'm not sure that leaving runtime
PM in "on" mode by default is the best choice here. But I've left
it like that for now at least.

Also remove the comment about there not being much benefit from
LPE audio runtime PM. Not allowing runtime PM blocks i915 runtime
PM, which will also block s0ix, and that could have a measurable
impact on power consumption.

Cc: Takashi Iwai 
Cc: Pierre-Louis Bossart 
Fixes: 0b6b524f3915 ("ALSA: x86: Don't enable runtime PM as default")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-2-ville.syrjala@linux.intel.com
Reviewed-by: Takashi Iwai 
(cherry picked from commit 183c00350ccda86781f6695840e6c5f5b22efbd1)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drivers: char: mem: Fix wraparound check to allow mappings up to the end

2017-06-14T13:07:50+00:00

commit 32829da54d9368103a2f03269a5120aa9ee4d5da upstream.

A recent fix to /dev/mem prevents mappings from wrapping around the end
of physical address space. However, the check was written in a way that
also prevents a mapping reaching just up to the end of physical address
space, which may be a valid use case (especially on 32-bit systems).
This patch fixes it by checking the last mapped address (instead of the
first address behind that) for overflow.

Fixes: b299cde245 ("drivers: char: mem: Check for address space wraparound with mmap()")
Reported-by: Nico Huber 
Signed-off-by: Julius Werner 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/tmr: fully separate alarm execution/pending lists

2017-06-14T13:07:49+00:00

commit b4e382ca7586a63b6c1e5221ce0863ff867c2df6 upstream.

Reusing the list_head for both is a bad idea.  Callback execution is done
with the lock dropped so that alarms can be rescheduled from the callback,
which means that with some unfortunate timing, lists can get corrupted.

The execution list should not require its own locking, the single function
that uses it can only be called from a single context.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Make sure backup_handle is always valid

2017-06-14T13:07:49+00:00

commit 07678eca2cf9c9a18584e546c2b2a0d0c9a3150c upstream.

When vmw_gb_surface_define_ioctl() is called with an existing buffer,
we end up returning an uninitialized variable in the backup_handle.

The fix is to first initialize backup_handle to 0 just to be sure, and
second, when a user-provided buffer is found, we will use the
req->buffer_handle as the backup_handle.

Reported-by: Murray McAllister 
Signed-off-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl()

2017-06-14T13:07:49+00:00

commit ee9c4e681ec4f58e42a83cb0c22a0289ade1aacf upstream.

The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
a user-controlled 'uint32_t' value which is used as a loop count limit.
This can lead to a kernel lockup and DoS. Add check for 'req->mip_levels'.

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1437431

Signed-off-by: Vladis Dronov 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Greg Kroah-Hartman