linux-stable.git/drivers/acpi, branch linux-3.17.y

Revert: ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC

2014-12-16T17:37:11+00:00

This reverts commit 2dbfff81a40b5b2be553042ad5c767e34fdd214c, which
really is commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream.

Sorry for the confusion, this got applied twice, and reverted once, this
is the second revert and I hope to never touch it again...

Reported-by: Lv Zheng 
Cc: Alexander Mezin 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up

2014-12-06T23:57:28+00:00

commit 78579b7c7eb45f0e7ec5e9437087ed21749f9a9c upstream.

As reported by Dmitry, on some Chromebooks there are devices with
corresponding ACPI objects and with unusual system wakeup
configuration.  Namely, they technically are wakeup-capable, but the
wakeup is handled via a platform-specific out-of-band mechanism and
the ACPI PM layer has no information on the wakeup capability.  As
a result, device_may_wakeup(dev) called from acpi_dev_suspend_late()
returns 'true' for those devices, but the wakeup.flags.valid flag is
unset for the corresponding ACPI device objects, so acpi_device_wakeup()
reproducibly fails for them causing acpi_dev_suspend_late() to return
an error code.  The entire system suspend is then aborted and the
machines in question cannot suspend at all.

Address the problem by ignoring the device_may_wakeup(dev) return
value in acpi_dev_suspend_late() if the ACPI companion of the device
being handled has wakeup.flags.valid unset (in which case it is clear
that the wakeup is supposed to be handled by other means).

This fixes a regression introduced by commit a76e9bd89ae7 (i2c:
attach/detach I2C client device to the ACPI power domain) as the
affected systems could suspend and resume successfully before that
commit.

Fixes: a76e9bd89ae7 (i2c: attach/detach I2C client device to the ACPI power domain)
Reported-by: Dmitry Torokhov 
Reviewed-by: Dmitry Torokhov 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Add support to disallow QR_EC to be issued before completing previous QR_EC

2014-12-06T23:57:28+00:00

commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream.

There is platform refusing to respond QR_EC when SCI_EVT isn't set
which is Acer Aspire V5-573G.

By disallowing QR_EC to be issued before the previous one has been
completed we are able to reduce the possibilities to trigger issues on
such platforms.

Note that this fix can only reduce the occurrence rate of this issue, but
this issue may still occur when such a platform doesn't clear SCI_EVT
before or immediately after completing the previous QR_EC transaction.
This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on
the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

But this patch is still useful as it can help to reduce the number of
scheduled QR_EC work items.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer.

2014-11-14T18:10:32+00:00

commit 79149001105f18bd2285ada109f9229ea24a7571 upstream.

It is reported that Samsung laptops that need to poll events are broken by
the following commit:
 Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
 Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

The behaviors of the 2 vendor firmwares are conflict:
 1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
         automatically sets SCI_EVT as long as there is event queued up.
 2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
            returns 0 when there is no event queued up.

This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.

Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Glück 
Signed-off-by: Lv Zheng 
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: invoke acpi_device_wakeup() with correct parameters

2014-11-14T18:10:32+00:00

commit 67598a1d3140a66f57aa6bcb8d22c4c2b7e910f5 upstream.

Fix a bug that invokes acpi_device_wakeup() with wrong parameters.

Fixes: f35cec255557 (ACPI / PM: Always enable wakeup GPEs when enabling device wakeup)
Signed-off-by: Zhang Rui 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Merge branches 'acpi-hotplug', 'acpi-scan', 'acpi-lpss', 'acpi-gpio' and 'acpi-video'

2014-09-25T20:59:30+00:00

* acpi-hotplug:
  ACPI / hotplug: Generate online uevents for ACPI containers

* acpi-scan:
  ACPI / scan: Correct error return value of create_modalias()

* acpi-lpss:
  ACPI / platform / LPSS: disable async suspend/resume of LPSS devices

* acpi-gpio:
  gpio / ACPI: Use pin index and bit length
  ACPICA: Update to GPIO region handler interface.

* acpi-video:
  ACPI / video: disable native backlight for ThinkPad X201s

ACPICA: Update to GPIO region handler interface.

2014-09-24T20:53:46+00:00

Changes to correct several GPIO issues:

1) The update_rule in a GPIO field definition is now ignored;
a read-modify-write operation is never performed for GPIO fields.
(Internally, this means that the field assembly/disassembly
code is completely bypassed for GPIO.)

2) The Address parameter passed to a GPIO region handler is
now the bit offset of the field from a previous Connection()
operator. Thus, it becomes a "Pin Number Index" into the
Connection() resource descriptor.

3) The bit_width parameter passed to a GPIO region handler is
now the exact bit width of the GPIO field. Thus, it can be
interpreted as "number of pins".

Overall, we can now say that the region handler interface
to GPIO handlers is a raw "bit/pin" addressed interface, not
a byte-addressed interface like the system_memory handler interface.

Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Cc: 3.15+  # 3.15+
Signed-off-by: Rafael J. Wysocki

ACPI / platform / LPSS: disable async suspend/resume of LPSS devices

2014-09-24T20:42:26+00:00

On some systems (Asus T100 in particular) there are strict ordering
dependencies between LPSS devices with respect to power management
that break if they suspend/resume asynchronously.

In theory it should be possible to follow those dependencies in the
async suspend/resume case too (the ACPI tables tell as that the
dependencies are there), but since we're missing infrastructure
for that at the moment, disable async suspend/resume for all of
the LPSS devices for the time being.

Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2
Fixes: 8ce62f85a81f (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices)
Signed-off-by: Li Aubrey 
Signed-off-by: Fu Zhonghui 
Cc: 3.16+  # 3.16+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki

ACPI / scan: Correct error return value of create_modalias()

2014-09-22T12:11:43+00:00

There is a typo, it should be negative -errno instead.

Signed-off-by: Mika Westerberg 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki

ACPI / video: disable native backlight for ThinkPad X201s

2014-09-22T12:06:01+00:00

The ThinkPad X201s has a working ACPI video backlight interface and is
shipped before Win8; then there is BIOS update that starts to query
_OSI("Windows 2012") and that would make our video module stop creating
backlight interface and caused problem for the user. Add it to the DMI
table to disable native backlight to fix this problem.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691
Link: https://bugzilla.kernel.org/show_bug.cgi?id=51231
Cc: 3.16+  # 3.16+
Reported-and-tested-by: Yves-Alexis Perez 
Signed-off-by: Aaron Lu 
Signed-off-by: Rafael J. Wysocki