linux-stable.git/drivers/platform, branch v3.16.67

platform/x86: alienware-wmi: Correct a memory leak

2018-12-16T22:09:15+00:00

commit ff0e9f26288d2daee4950f42b37a3d3d30d36ec1 upstream.

An ACPI buffer that was allocated was not being freed after use.

Signed-off-by: Mario Limonciello 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Ben Hutchings

platform/x86: ideapad-laptop: Apply no_hw_rfkill to Y20-15IKBM, too

2018-12-16T22:08:05+00:00

commit 58e73aa177850babb947555257fd4f79e5275cf1 upstream.

The commit 5d9f40b56630 ("platform/x86: ideapad-laptop: Add
Y520-15IKBN to no_hw_rfkill") added the entry for Y20-15IKBN, and it
turned out that another variant, Y20-15IKBM, also requires the
no_hw_rfkill.

Trim the last letter from the string so that it matches to both
Y20-15IKBN and Y20-15IKBM models.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1098626
Signed-off-by: Takashi Iwai 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Ben Hutchings

platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill

2018-12-16T22:08:05+00:00

commit 5d9f40b56630a8702b5f7a61a770f9b73aa07464 upstream.

Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Ben Hutchings

eeepc-laptop: simplify parse_arg()

2018-11-20T18:04:45+00:00

commit 95369a73a957ad221f1d6b8f11a63a376f38c544 upstream.

parse_arg() has three possible return values:
    -EINVAL if sscanf(), in short, fails;
    zero if "count" is zero; and
    "count" in all other cases

But "count" will never be zero. See, parse_arg() is called by the
various store functions. And the callchain of these functions starts
with sysfs_kf_write(). And that function checks for a zero "count". So
we can stop checking for a zero "count", drop the "count" argument
entirely, and transform parse_arg() into a function that returns zero on
success or a negative error. That, in turn, allows to make those store
functions just return "count" on success. The net effect is that the
code becomes a bit easier to understand.

A nice side effect is that this GCC warning is silenced too:
    drivers/platform/x86/eeepc-laptop.c: In function ‘store_sys_acpi’:
    drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      int rv, value;

Which is, of course, the reason to have a look at parse_arg().

Signed-off-by: Paul Bolle 
Signed-off-by: Darren Hart 
Signed-off-by: Ben Hutchings

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

2018-06-16T21:22:03+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 
Signed-off-by: Darren Hart (VMware) 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()

2018-02-13T18:42:15+00:00

commit f6c8a317ab208aee223776327c06f23342492d54 upstream.

Source code review for a specific software refactoring showed the need
for another correction because the error code "-1" was returned so far
if a call of the function "sony_call_snc_handle" failed here.
Thus assign the return value from these two function calls also to
the variable "err" and provide it in case of a failure.

Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw")
Suggested-by: Andy Shevchenko 
Link: https://lkml.org/lkml/2017/10/31/463
Link: https://lkml.kernel.org/r/
Signed-off-by: Markus Elfring 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Ben Hutchings

platform/x86: samsung-laptop: Initialize loca variable

2017-11-11T13:33:41+00:00

commit 0d2c95354a3b63256e92d9fb865c08902d2c9b0b upstream.

The variable is used uninitialized which might come into unexpected
behaviour on some Samsung laptops.

Initialize it to 0xffff which seems a proper value for non-supported
feature.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Ben Hutchings

platform/x86: acer-wmi: setup accelerometer when machine has appropriate notify event

2017-06-05T20:17:22+00:00

commit 98d610c3739ac354319a6590b915f4624d9151e6 upstream.

The accelerometer event relies on the ACERWMID_EVENT_GUID notify.
So, this patch changes the codes to setup accelerometer input device
when detected ACERWMID_EVENT_GUID. It avoids that the accel input
device created on every Acer machines.

In addition, patch adds a clearly parsing logic of accelerometer hid
to acer_wmi_get_handle_cb callback function. It is positive matching
the "SENR" name with "BST0001" device to avoid non-supported hardware.

Reported-by: Bjørn Mork 
Cc: Darren Hart 
Signed-off-by: Lee, Chun-Yi 
[andy: slightly massage commit message]
Signed-off-by: Andy Shevchenko 
Signed-off-by: Ben Hutchings

goldfish: Sanitize the broken interrupt handler

2017-06-05T20:17:09+00:00

commit 6cf18e6927c0b224f972e3042fb85770d63cb9f8 upstream.

This interrupt handler is broken in several ways:

  - It loops forever when the op code is not decodeable

  - It never returns IRQ_HANDLED because the only way to exit the loop
    returns IRQ_NONE unconditionally.

The whole concept of this is broken. Creating devices in an interrupt
handler is beyond any point of sanity.

Make it at least behave halfways sane so accidental users do not have to
deal with a hard to debug lockup.

Fixes: e809c22b8fb028 ("goldfish: add the goldfish virtual bus")
Reported-by: Gabriel C 
Signed-off-by: Thomas Gleixner 
Acked-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT

2017-03-16T02:27:04+00:00

commit 5a00b6c2438460b870a451f14593fc40d3c7edf6 upstream.

The commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
starts refusing misconfigured interrupt handlers. This makes
intel_mid_powerbtn not working anymore.

Add a mandatory flag to a threaded IRQ request in the driver.

Fixes: 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
Signed-off-by: Andy Shevchenko 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings