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

HID: i2c-hid: fix inverted return value from i2c_hid_command()

2018-04-24T07:43:10+00:00

commit b658912cb023cd6f8e46963d29779903d3c10538 upstream.

i2c_hid_command() returns non-zero in error cases (the actual
errno). Error handling in for I2C_HID_QUIRK_RESEND_REPORT_DESCR
case in i2c_hid_resume() had the check inverted; fix that.

Fixes: 3e83eda467 ("HID: i2c-hid: Fix resume issue on Raydium touchscreen device")
Reported-by: Dan Carpenter 
Signed-off-by: Jiri Kosina 
Cc: Aaron Ma 
Signed-off-by: Greg Kroah-Hartman

drm/i915/gvt: init mmio by lri command in vgpu inhibit context

2018-04-24T07:43:10+00:00

commit cd7e61b93d068a80bfe6cb55bf00f17332d831a1 upstream.

There is one issue relates to Coarse Power Gating(CPG) on KBL NUC in GVT-g,
vgpu can't get the correct default context by updating the registers before
inhibit context submission. It always get back the hardware default value
unless the inhibit context submission happened before the 1st time
forcewake put. With this wrong default context, vgpu will run with
incorrect state and meet unknown issues.

The solution is initialize these mmios by adding lri command in ring buffer
of the inhibit context, then gpu hardware has no chance to go down RC6 when
lri commands are right being executed, and then vgpu can get correct
default context for further use.

v3:
- fix code fault, use 'for' to loop through mmio render list(Zhenyu)

v4:
- save the count of engine mmio need to be restored for inhibit context and
  refine some comments. (Kevin)

v5:
- code rebase

Cc: Kevin Tian 
Cc: Zhenyu Wang 
Signed-off-by: Weinan Li 
Signed-off-by: Zhenyu Wang 
Signed-off-by: Changbin Du 
Signed-off-by: Greg Kroah-Hartman

device-dax: allow MAP_SYNC to succeed

2018-04-24T07:43:10+00:00

commit ef8423022324cf79bd1b41d8707c766461e7e555 upstream.

MAP_SYNC is a nop for device-dax. Allow MAP_SYNC to succeed on device-dax
to eliminate special casing between device-dax and fs-dax as to when the
flag can be specified. Device-dax users already implicitly assume that they do
not need to call fsync(), and this enables them to explicitly check for this
capability.

Cc: 
Fixes: b6fb293f2497 ("mm: Define MAP_SYNC and VM_SYNC flags")
Signed-off-by: Dave Jiang 
Reviewed-by: Dan Williams 
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

libnvdimm, dimm: handle EACCES failures from label reads

2018-04-24T07:43:10+00:00

commit e7c5a571a8d6a266aee9ca3f3f26e5afe3717eca upstream.

The new support for the standard _LSR and _LSW methods neglected to also
update the nvdimm_init_config_data() and nvdimm_set_config_data() to
return the translated error code from failed commands. This precision is
necessary because the locked status that was previously returned on
ND_CMD_GET_CONFIG_SIZE commands is now returned on
ND_CMD_{GET,SET}_CONFIG_DATA commands.

If the kernel misses this indication it can inadvertently fall back to
label-less mode when it should otherwise avoid all access to locked
regions.

Cc: 
Fixes: 4b27db7e26cd ("acpi, nfit: add support for the _LSI, _LSR, and...")
Signed-off-by: Dan Williams 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

2018-04-24T07:43:09+00:00

commit 5deae9191130db6b617c94fb261804597cf9b508 upstream.

Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).

On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.

This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.

One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.

v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)

Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Stone 
Cc: Russell King - ARM Linux 
Cc: Ilia Mirkin 
Cc: Hans Verkuil 
Cc: Shashank Sharma 
Cc: Uma Shankar 
Cc: Jyri Sarha 
Cc: "Tang, Jun" 
Reported-by: "Tang, Jun" 
Cc: stable@vger.kernel.org
Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4")
Reviewed-by: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix hibernation with ACPI S0 target state

2018-04-24T07:43:09+00:00

commit 300efa9eea451bdcf3b5a1eb292222e06e85bb2c upstream.

After

commit dd9f31c7a3887950cbd0d49eb9d43f7a1518a356
Author: Imre Deak 
Date:   Wed Aug 16 17:46:07 2017 +0300

    drm/i915/gen9+: Set same power state before hibernation image
    save/restore

during hibernation/suspend the power domain functionality got disabled,
after which resume could leave it incorrectly disabled if the ACPI
target state was S0 during suspend and i915 was not loaded by the loader
kernel.

This was caused by not considering if we resumed from hibernation as the
condition for power domains reiniting.

Fix this by simply tracking if we suspended power domains during system
suspend and reinit power domains accordingly during resume. This will
result in reiniting power domains always when resuming from hibernation,
regardless of the platform and whether or not i915 is loaded by the
loader kernel.

The reason we didn't catch this earlier is that the enabled/disabled
state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform
and kernel config dependent: on my SKL the target state is S4
during PMSG_FREEZE and (with the driver loaded in the loader kernel)
S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during
PMSG_FREEZE but (contrary to this) power domains are not initialized
during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or
it's loaded but without the DMC firmware being available.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196
Reported-and-tested-by: amn-bas@hotmail.com
Fixes: dd9f31c7a388 ("drm/i915/gen9+: Set same power state before hibernation image save/restore")
Cc: amn-bas@hotmail.com
Cc: Ville Syrjälä 
Cc: 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180322143642.26883-1-imre.deak@intel.com
(cherry picked from commit 0f90603c33bdf6575cfdc81edd53f3f13ba166fb)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pci: Only do AMD tuning for HS200

2018-04-24T07:43:09+00:00

commit 300ad8992913025b4294d4fc37b6bfff4a8b7ad1 upstream.

Commit c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode
on AMD, eMMC-4.5.1") added a HS200 tuning method for use with AMD SDHCI
controllers.  As described in the commit subject, this tuning is specific
for HS200.  However, as implemented, this method is used for all host
timings, because platform_execute_tuning, if it exists, is called
unconditionally by sdhci_execute_tuning().  This breaks tuning when using
the AMD controller with, for example, a DDR50 SD card.

Instead, we can implement an amd execute_tuning wrapper callback, and
then conditionally do the HS200 specific tuning for HS200, and otherwise
call back to the standard sdhci_execute_tuning().

Signed-off-by: Daniel Kurtz 
Acked-by: Shyam Sundar S K 
Acked-by: Adrian Hunter 
Fixes: c31165d7400b ("mmc: sdhci-pci: Add support for HS200 tuning mode on AMD, eMMC-4.5.1")
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman

HID: wacom: bluetooth: send exit report for recent Bluetooth devices

2018-04-24T07:43:08+00:00

commit 619d3a2922ce623ca2eca443cc936810d328317c upstream.

The code path for recent Bluetooth devices omits an exit report which
resets all the values of the device.

Fixes: 4922cd26f0 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface")
Cc:  # 4.11
Signed-off-by: Aaron Armstrong Skomra 
Reviewed-by: Ping Cheng 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: hidraw: Fix crash on HIDIOCGFEATURE with a destroyed device

2018-04-24T07:43:07+00:00

commit a955358d54695e4ad9f7d6489a7ac4d69a8fc711 upstream.

Doing `ioctl(HIDIOCGFEATURE)` in a tight loop on a hidraw device
and then disconnecting the device, or unloading the driver, can
cause a NULL pointer dereference.

When a hidraw device is destroyed it sets 0 to `dev->exist`.
Most functions check 'dev->exist' before doing its work, but
`hidraw_get_report()` was missing that check.

Cc: stable@vger.kernel.org
Signed-off-by: Rodrigo Rivas Costa 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: input: fix battery level reporting on BT mice

2018-04-24T07:43:07+00:00

commit 2e210bbb7429cdcf1a1a3ad00c1bf98bd9bf2452 upstream.

The commit 581c4484769e ("HID: input: map digitizer battery usage")
assumed that devices having input (qas opposed to feature) report for
battery strength would report the data on their own, without the need to
be polled by the kernel; unfortunately it is not so. Many wireless mice
do not send unsolicited reports with battery strength data and have to
be polled explicitly. As a complication, stylus devices on digitizers
are not normally connected to the base and thus can not be polled - the
base can only determine battery strength in the stylus when it is in
proximity.

To solve this issue, we add a special flag that tells the kernel
to avoid polling the device (and expect unsolicited reports) and set it
when report field with physical usage of digitizer stylus (HID_DG_STYLUS).
Unless this flag is set, and we have not seen the unsolicited reports,
the kernel will attempt to poll the device when userspace attempts to
read "capacity" and "state" attributes of power_supply object
corresponding to the devices battery.

Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin van Es 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman