litmus-rt-edfsc.git/drivers/platform, branch wip-joshua

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

2017-04-21T07:31:24+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 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

platform/x86: asus-wmi: Detect quirk_no_rfkill from the DSDT

2017-04-12T10:41:22+00:00

[ Upstream commit 71050ae7bf83e4d71a859257d11adc5de517073e ]

Some Asus laptops that have an airplane-mode indicator LED, also have
the WMI WLAN user bit set, and the following bits in their DSDT:

    Scope (_SB)
    {
      (...)
      Device (ATKD)
      {
        (...)
        Method (WMNB, 3, Serialized)
        {
          (...)
          If (LEqual (IIA0, 0x00010002))
          {
            OWGD (IIA1)
            Return (One)
          }
        }
      }
    }

So when asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the
wlan state, it drives the airplane-mode indicator LED (through the call
to OWGD) in an inverted fashion: the LED is ON when airplane mode is OFF
(since wlan is ON), and vice-versa.

This commit skips registering RFKill switches at all for these laptops,
to allow the asus-wireless driver to drive the airplane mode LED
correctly through the ASHS ACPI device. Relying on the presence of ASHS
and ASUS_WMI_DSTS_USER_BIT avoids adding DMI-based quirks for at least
21 different laptops.

Signed-off-by: João Paulo Rechi Vita 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

platform/x86: asus-wmi: Set specified XUSB2PR value for X550LB

2017-04-12T10:41:22+00:00

[ Upstream commit 8023eff10e7b0327898f17f0b553d2e45c71cef3 ]

The bluetooth adapter Atheros AR3012 can't be enumerated
and make the bluetooth function broken.

T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=13d3 ProdID=3362 Rev=00.02
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

The error is:

 usb 2-6: device not accepting address 7, error -62
 usb usb2-port6: unable to enumerate USB device

It is caused by adapter's connected port is mapped to xHC
controller, but the xHCI is not supported by the usb device.

The output of 'sudo lspci -nnxxx -s 00:14.0':

 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC [8086:9c31] (rev 04)
 00: 86 80 31 9c 06 04 90 02 04 30 03 0c 00 00 00 00
 10: 04 00 a0 f7 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 1f 20
 30: 00 00 00 00 70 00 00 00 00 00 00 00 0b 01 00 00
 40: fd 01 36 80 89 c6 0f 80 00 00 00 00 00 00 00 00
 50: 5f 2e ce 0f 00 00 00 00 00 00 00 00 00 00 00 00
 60: 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 01 80 c2 c1 08 00 00 00 00 00 00 00 00 00 00 00
 80: 05 00 87 00 0c a0 e0 fe 00 00 00 00 a1 41 00 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00 00
 b0: 0f 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
 c0: 03 c0 30 00 00 00 00 00 03 0c 00 00 00 00 00 00
 d0: f9 01 00 00 f9 01 00 00 0f 00 00 00 0f 00 00 00
 e0: 00 08 00 00 00 00 00 00 00 00 00 00 d8 d8 00 00
 f0: 00 00 00 00 00 00 00 00 b1 0f 04 08 00 00 00 00

By referencing Intel Platform Controller Hub(PCH) datasheet,
the xHC USB 2.0 Port Routing(XUSB2PR) at offset 0xD0-0xD3h
decides the setting of mapping the port to EHCI controller or
xHC controller. And the port mapped to xHC will enable xHCI
during bus resume.

The setting of disabling bluetooth adapter's connected port is
0x000001D9. The value can be obtained by few times 1 bit flip
operation. The suited configuration should have the 'lsusb -t'
result with bluetooth using ehci:

/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M
    |__ Port 5: Dev 2, If 0, Class=Video, Driver=uvcvideo, 480M
    |__ Port 5: Dev 2, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
        |__ Port 6: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 6: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M

Signed-off-by: Kai-Chuan Hsieh 
Acked-by: Corentin Chary 
Reviewed-by: Andy Shevchenko 
[andy: resolve merge conflict in asus-wmi.h]
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

platform/x86: acer-wmi: Only supports AMW0_GUID1 on acer family

2017-04-12T10:41:17+00:00

[ Upstream commit 5241b1938a4d33eee3d3b43f23067c8e5b96db45 ]

The AMW0_GUID1 wmi is not only found on Acer family but also other
machines like Lenovo, Fujitsu and Medion. In the past, acer-wmi handled
those non-Acer machines by quirks list.

But actually acer-wmi driver was loaded on any machine that had
AMW0_GUID1. This behavior is strange because those machines should be
supported by appropriate wmi drivers. e.g. fujitsu-laptop,
ideapad-laptop.

This patch adds the logic to check the machine that has AMW0_GUID1
should be in Acer/Packard Bell/Gateway white list. But, it still keeps
the quirk list of those supported non-acer machines for backward
compatibility.

Tested-by: Bjørn Mork 
Signed-off-by: Lee, Chun-Yi 
Signed-off-by: Darren Hart 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

goldfish: Sanitize the broken interrupt handler

2017-02-26T10:10:52+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

platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT

2017-02-01T07:33:14+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 
Signed-off-by: Greg Kroah-Hartman

platform/x86: fujitsu-laptop: use brightness_set_blocking for LED-setting callbacks

2017-01-12T10:39:25+00:00

commit a608a9d52fa4168efd478d684039ed545a69dbcd upstream.

All LED-setting functions in fujitsu-laptop are currently assigned to
the brightness_set callback, which is incorrect because they can sleep
(due to their use of call_fext_func(), which in turn issues ACPI calls)
and the documentation (in include/linux/leds.h) clearly states they must
not.  Assign them to brightness_set_blocking instead and change them to
match the expected function prototype.

This change makes it possible to use Fujitsu-specific LEDs with "heavy"
triggers, like disk-activity or phy0rx.

Fixes: 3a407086090b ("fujitsu-laptop: Add BL power, LED control and radio state information")
Fixes: 4f62568c1fcf ("fujitsu-laptop: Support radio LED")
Fixes: d6b88f64b0d4 ("fujitsu-laptop: Add support for eco LED")
Signed-off-by: Michał Kępień 
Acked-by: Jonathan Woithe 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

platform/x86: asus-nb-wmi.c: Add X45U quirk

2017-01-09T07:32:23+00:00

commit e74e259939275a5dd4e0d02845c694f421e249ad upstream.

Without this patch, the Asus X45U wireless card can't be turned
on (hard-blocked), but after a suspend/resume it just starts working.

Following this bug report[1], there are other cases like this one, but
this Asus is the only model that I can test.

[1] https://ubuntuforums.org/showthread.php?t=2181558

Signed-off-by: Marcos Paulo de Souza 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'acpi-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2016-11-12T01:02:01+00:00

Pull ACPI fix from Rafael Wysocki:
 "Fix a recent regression in the 8250_dw serial driver introduced by
  adding a quirk for the APM X-Gene SoC to it which uncovered an issue
  related to the handling of built-in device properties in the core ACPI
  device enumeration code (Heikki Krogerus)"

* tag 'acpi-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / platform: Add support for build-in properties

Merge branch 'device-properties'

2016-11-11T22:23:02+00:00

* device-properties:
  ACPI / platform: Add support for build-in properties