linux.git/drivers/platform, branch v4.14.34

platform/chrome: Use proper protocol transfer function

2018-03-24T10:01:23+00:00

[ Upstream commit d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ]

pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
one instance of these functions correct, but not the second, fall-back
case. We use the fall-back only when the first command returns an
IN_PROGRESS status, which is only used on some EC firmwares where we
don't want to constantly poll the bus, but instead back off and
sleep/retry for a little while.

Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton")
Signed-off-by: Shawn Nematbakhsh 
Signed-off-by: Brian Norris 
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Benson Leung 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cros_ec: fix nul-termination for firmware build info

2018-03-24T10:01:23+00:00

[ Upstream commit 50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]

As gcc-8 reports, we zero out the wrong byte:

drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript 4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]

This changes the code back to what it did before changing to a
zero-length array structure.

Fixes: a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Benson Leung 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

platform/x86: dell-laptop: Fix keyboard max lighting for Dell Latitude E6410

2018-02-25T10:08:03+00:00

[ Upstream commit 68a213d325c23d39f109f4c7c824b906a7d209de ]

This machine reports number of keyboard backlight led levels, instead of
value of the last led level index. Therefore max_brightness properly needs
to be subtracted by 1 to match led max_brightness API.

Signed-off-by: Pali Rohár 
Reported-by: Gabriel M. Elder 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196913
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Revert "apple-gmux: lock iGP IO to protect from vgaarb changes"

2018-02-22T14:42:26+00:00

commit d6fa7588fd7a8def4c747c0c574ce85d453e3788 upstream.

Commit 4eebd5a4e726 ("apple-gmux: lock iGP IO to protect from vgaarb
changes") amended this driver's ->probe hook to lock decoding of normal
(non-legacy) I/O space accesses to the integrated GPU on dual-GPU
MacBook Pros.  The lock stays in place until the driver is unbound.

The change was made to work around an issue with the out-of-tree nvidia
graphics driver (available at http://www.nvidia.com/object/unix.html).
It contains the following sequence in nvidia/nv.c:

	#if defined(CONFIG_VGA_ARB) && !defined(NVCPU_PPC64LE)
	#if defined(VGA_DEFAULT_DEVICE)
	    vga_tryget(VGA_DEFAULT_DEVICE, VGA_RSRC_LEGACY_MASK);
	#endif
	    vga_set_legacy_decoding(dev, VGA_RSRC_NONE);
	#endif

This code was reported to cause deadlocks with VFIO already in 2013:
https://devtalk.nvidia.com/default/topic/545560

I've reported the issue to Nvidia developers once more in 2017:
https://www.spinics.net/lists/dri-devel/msg138754.html

On the MacBookPro10,1, this code apparently breaks backlight control
(which is handled by apple-gmux via an I/O region starting at 0x700),
as reported by Petri Hodju:
https://bugzilla.kernel.org/show_bug.cgi?id=86121

I tried to replicate Petri's observations on my MacBook9,1, which uses
the same Intel Ivy Bridge + Nvidia GeForce GT 650M architecture, to no
avail.  On my machine apple-gmux' I/O region remains accessible even
with the nvidia driver loaded and commit 4eebd5a4e726 reverted.
Petri reported that apple-gmux becomes accessible again after a
suspend/resume cycle because the BIOS changed the VGA routing on the
root port to the Nvidia GPU.  Perhaps this is a BIOS issue after all
that can be fixed with an update?

In any case, the change made by commit 4eebd5a4e726 has turned out to
cause two new issues:

* Wilfried Klaebe reports a deadlock when launching Xorg because it
  opens /dev/vga_arbiter and calls vga_get(), but apple-gmux is holding
  a lock on I/O space indefinitely.  It looks like apple-gmux' current
  behavior is an abuse of the vgaarb API as locks are not meant to be
  held for longer periods:
  https://bugzilla.kernel.org/show_bug.cgi?id=88861#c11
  https://bugzilla.kernel.org/attachment.cgi?id=217541

* On dual GPU MacBook Pros introduced since 2013, the integrated GPU is
  powergated on boot und thus becomes invisible to Linux unless a custom
  EFI protocol is used to leave it powered on.  (A patch exists but is
  not in mainline yet due to several negative side effects.)  On these
  machines, locking I/O to the integrated GPU (as done by 4eebd5a4e726)
  fails and backlight control is therefore broken:
  https://bugzilla.kernel.org/show_bug.cgi?id=105051

So let's revert commit 4eebd5a4e726 please.  Users experiencing the
issue with the proprietary nvidia driver can comment out the above-
quoted problematic code as a workaround (or try updating the BIOS).

Cc: Petri Hodju 
Cc: Bjorn Helgaas 
Cc: Bruno Prémont 
Cc: Andy Ritger 
Cc: Ronald Tschalär 
Tested-by: Wilfried Klaebe 
Signed-off-by: Lukas Wunner 
Cc: stable@vger.kernel.org
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Greg Kroah-Hartman

platform/x86: wmi: Call acpi_wmi_init() later

2018-01-17T08:45:18+00:00

commit 98b8e4e5c17bf87c1b18ed929472051dab39878c upstream.

Calling acpi_wmi_init() at the subsys_initcall() level causes ordering
issues to appear on some systems and they are difficult to reproduce,
because there is no guaranteed ordering between subsys_initcall()
calls, so they may occur in different orders on different systems.

In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache
creation delayed issue) exposed one of these issues where genl_init()
and acpi_wmi_init() are both called at the same initcall level, but
the former must run before the latter so as to avoid a NULL pointer
dereference.

For this reason, move the acpi_wmi_init() invocation to the
initcall_sync level which should still be early enough for things
to work correctly in the WMI land.

Link: https://marc.info/?t=151274596700002&r=1&w=2
Reported-by: Jonathan McDowell 
Reported-by: Joonsoo Kim 
Tested-by: Jonathan McDowell 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Greg Kroah-Hartman

platform/x86: asus-wireless: send an EV_SYN/SYN_REPORT between state changes

2017-12-25T13:26:31+00:00

commit bff5bf9db1c9453ffd0a78abed3e2d040c092fd9 upstream.

Sending the switch state change twice within the same frame is invalid
evdev protocol and only works if the client handles keys immediately as
well. Processing events immediately is incorrect, it forces a fake
order of events that does not exist on the device.

Recent versions of libinput changed to only process the device state and
SYN_REPORT time, so now the key event is lost.

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

Signed-off-by: Peter Hutterer 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Greg Kroah-Hartman

platform/x86: hp_accel: Add quirk for HP ProBook 440 G4

2017-12-20T09:10:31+00:00

[ Upstream commit 163ca80013aafb6dc9cb295de3db7aeab9ab43f8 ]

Added support for HP ProBook 440 G4 laptops by including the accelerometer
orientation quirk for that device. Testing was performed based on the
axis orientation guidelines here:
https://www.kernel.org/doc/Documentation/misc-devices/lis3lv02d
which states "If the left side is elevated, X increases (becomes positive)".

When tested, on lifting the left edge, x values became increasingly negative
thus indicating an inverted x-axis on the installed lis3lv02d chip.
This was compensated by adding an entry for this device in hp_accel.c
specifying the quirk as x_inverted. The patch was tested on a
ProBook 440 G4 device and x-axis as well as y and z-axis values are now
generated as per spec.

Signed-off-by: Osama Khan 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

platform/x86: intel_punit_ipc: Fix resource ioremap warning

2017-12-20T09:10:25+00:00

[ Upstream commit 6cc8cbbc8868033f279b63e98b26b75eaa0006ab ]

For PUNIT device, ISPDRIVER_IPC and GTDDRIVER_IPC resources are not
mandatory. So when PMC IPC driver creates a PUNIT device, if these
resources are not available then it creates dummy resource entries for
these missing resources. But during PUNIT device probe, doing ioremap on
these dummy resources generates following warning messages.

intel_punit_ipc: can't request region for resource [mem 0x00000000]
intel_punit_ipc: can't request region for resource [mem 0x00000000]
intel_punit_ipc: can't request region for resource [mem 0x00000000]
intel_punit_ipc: can't request region for resource [mem 0x00000000]

This patch fixes this issue by adding extra check for resource size
before performing ioremap operation.

Signed-off-by: Kuppuswamy Sathyanarayanan 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

platform/x86: hp-wmi: Fix tablet mode detection for convertibles

2017-12-05T10:26:27+00:00

commit 9968e12a291e639dd51d1218b694d440b22a917f upstream.

Commit f9cf3b2880cc ("platform/x86: hp-wmi: Refactor dock and tablet
state fetchers") consolidated the methods for docking and laptop mode
detection, but omitted to apply the correct mask for the laptop mode
(it always uses the constant for docking).

Fixes: f9cf3b2880cc ("platform/x86: hp-wmi: Refactor dock and tablet state fetchers")
Signed-off-by: Stefan Brüns 
Cc: Michel Dänzer 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table

2017-11-21T08:49:23+00:00

commit d6fa71f1c003fb2bc824276bb424a4171f9a717f upstream.

Add missing terminating entry to peaq_dmi_table.

Fixes: 3b95206110a2 ("platform/x86: peaq-wmi: Add DMI check before ...")
Reported-by: Fengguang Wu 
Signed-off-by: Hans de Goede 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman