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

platform/x86: sony-laptop: Fix unintentional fall-through

2019-09-23T20:12:02+00:00

commit 1cbd7a64959d33e7a2a1fa2bf36a62b350a9fcbd upstream.

It seems that the default case should return AE_CTRL_TERMINATE, instead
of falling through to case ACPI_RESOURCE_TYPE_END_TAG and returning AE_OK;
otherwise the line of code at the end of the function is unreachable and
makes no sense:

return AE_CTRL_TERMINATE;

This fix is based on the following thread of discussion:

https://lore.kernel.org/patchwork/patch/959782/

Fixes: 33a04454527e ("sony-laptop: Add SNY6001 device handling (sonypi reimplementation)")
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Kees Cook 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Ben Hutchings

platform/x86: alienware-wmi: printing the wrong error code

2019-09-23T20:12:02+00:00

commit 6d1f8b3d75419a8659ac916a1e9543bb3513a882 upstream.

The "out_data" variable is uninitialized at the point.  Originally, this
used to print "status" instead and that seems like the correct thing to
print.

Fixes: bc2ef884320b ("alienware-wmi: For WMAX HDMI method, introduce a way to query HDMI cable status")
Signed-off-by: Dan Carpenter 
Reviewed-by: Mario Limonciello 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Ben Hutchings

platform/x86: alienware-wmi: fix kfree on potentially uninitialized pointer

2019-09-23T20:11:44+00:00

commit 98e2630284ab741804bd0713e932e725466f2f84 upstream.

Currently the kfree of output.pointer can be potentially freeing
an uninitalized pointer in the case where out_data is NULL. Fix this
by reworking the case where out_data is not-null to perform the
ACPI status check and also the kfree of outpoint.pointer in one block
and hence ensuring the pointer is only freed when it has been used.

Also replace the if (ptr != NULL) idiom with just if (ptr).

Fixes: ff0e9f26288d ("platform/x86: alienware-wmi: Correct a memory leak")
Signed-off-by: Colin Ian King 
Signed-off-by: Darren Hart (VMware) 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

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