linux-stable.git/drivers/acpi, branch v3.12.35

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

2014-11-05T09:03:18+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 
Cc: 3.17+  # 3.17+
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki 

Signed-off-by: Jiri Slaby

ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set

2014-11-05T09:03:18+00:00

commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 upstream.

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

Currently, we rely on the behaviour that the EC firmware can respond
something (for example, 0x00 to indicate "no outstanding events") to
QR_EC even when SCI_EVT is not set, but the reporter has complained
about AC/battery pluging/unpluging and video brightness change delay
on that platform.

This is because the work item that has issued QR_EC has to wait until
timeout in this case, and the _Qxx method evaluation work item queued
after QR_EC one is delayed.

It sounds reasonable to fix this issue by:
 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC
    driver's main state machine.
 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation
    to a seperate IRQ handling thread.

This patch fixes this issue using solution 1.

By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to
handle such platform in the EC driver's main state machine. This patch
enhances the state machine in this way to survive with such malfunctioning
EC firmware.

Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies
on the assumption that the platforms are able to respond even when SCI_EVT
isn't set.

Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed()
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Reported-and-tested-by: Alexander Mezin 
Signed-off-by: Lv Zheng 
Cc: 3.16+  # 3.16+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / RTC: Fix CMOS RTC opregion handler accesses to wrong addresses

2014-10-13T13:41:04+00:00

commit 9389f46e9782ea5e56fbd7b2e59ba7c08f3ba86b upstream.

The value64 parameter is an u64 point that used to transfer the value
for write to CMOS, or used to return the value that's read from CMOS.

The value64 is an u64 point, so don't need get address again. It causes
acpi_cmos_rtc_space_handler always return 0 to reader and didn't write
expected value to CMOS.

Signed-off-by: Lee, Chun-Yi 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock

2014-09-17T14:55:09+00:00

commit 6726655dfdd2dc60c035c690d9f10cb69d7ea075 upstream.

There is a following AB-BA dependency between cpu_hotplug.lock and
cpuidle_lock:

1) cpu_hotplug.lock -> cpuidle_lock
enable_nonboot_cpus()
 _cpu_up()
  cpu_hotplug_begin()
   LOCK(cpu_hotplug.lock)
 cpu_notify()
  ...
  acpi_processor_hotplug()
   cpuidle_pause_and_lock()
    LOCK(cpuidle_lock)

2) cpuidle_lock -> cpu_hotplug.lock
acpi_os_execute_deferred() workqueue
 ...
 acpi_processor_cst_has_changed()
  cpuidle_pause_and_lock()
   LOCK(cpuidle_lock)
  get_online_cpus()
   LOCK(cpu_hotplug.lock)

Fix this by reversing the order acpi_processor_cst_has_changed() does
thigs -- let it first execute the protection against CPU hotplug by
calling get_online_cpus() and obtain the cpuidle lock only after that (and
perform the symmentric change when allowing CPUs hotplug again and
dropping cpuidle lock).

Spotted by lockdep.

Signed-off-by: Jiri Kosina 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPICA: Utilities: Fix memory leak in acpi_ut_copy_iobject_to_iobject

2014-09-17T14:55:09+00:00

commit 8aa5e56eeb61a099ea6519eb30ee399e1bc043ce upstream.

Adds return status check on copy routines to delete the allocated destination
object if either copy fails. Reported by Colin Ian King on bugs.acpica.org,
Bug 1087.
The last applicable commit:
 Commit: 3371c19c294a4cb3649aa4e84606be8a1d999e61
 Subject: ACPICA: Remove ACPI_GET_OBJECT_TYPE macro

Link: https://bugs.acpica.org/show_bug.cgi?id=1087
Reported-by: Colin Ian King 
Signed-off-by: David E. Box 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / resources: only reject zero length resources based at address zero

2014-07-28T07:12:21+00:00

commit 867f9d463b82462793ea4610e748be0b04b37fc7 upstream.

The recently merged change (in v3.14-rc6) to ACPI resource detection
(below) causes all zero length ACPI resources to be elided from the
table:

  commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
  Author: Zhang Rui 
  Date:   Thu Feb 27 11:37:15 2014 +0800

    ACPI / resources: ignore invalid ACPI device resources

This change has caused a regression in (at least) serial port detection
for a number of machines (see LP#1313981 [1]).  These seem to represent
their IO regions (presumably incorrectly) as a zero length region.
Reverting the above commit restores these serial devices.

Only elide zero length resources which lie at address 0.

Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Andy Whitcroft 
Acked-by: Zhang Rui 
Cc: 3.14+  # 3.14+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / battery: Retry to get battery information if failed during probing

2014-07-18T13:51:31+00:00

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream.

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

[ backport to 3.14.5: removed second parameter in acpi_battery_update(),
introduced by the commit 9e50bc14a7f58b5d8a55973b2d69355852ae2dae (ACPI /
battery: Accelerate battery resume callback)]

[naszar : backport to 3.14.5]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581
Reported-and-tested-by: naszar 
Cc: All applicable 
Signed-off-by: Lan Tianyu 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / EC: Fix race condition in ec_transaction_completed()

2014-07-18T13:51:19+00:00

commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream.

There is a race condition in ec_transaction_completed().

When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.

The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.

After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams 
Reported-and-tested-by: Hans de Goede 
Reported-by: Barton Xu 
Tested-by: Steffen Weber 
Tested-by: Arthur Chen 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / EC: Remove duplicated ec_wait_ibf0() waiter

2014-07-18T13:51:19+00:00

commit 9b80f0f73ae1583c22325ede341c74195847618c upstream.

After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
   If IBF=1 blocked the first command byte write invoked in the task
   context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
   out and retried again in the task context.

Remove this seperate and duplicate IBF=0 waiter.  By doing so we can
reduce the overall number of times to access the EC_SC(R) status
register.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams 
Reported-and-tested-by: Hans de Goede 
Reported-by: Barton Xu 
Tested-by: Steffen Weber 
Tested-by: Arthur Chen 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

ACPI / EC: Add asynchronous command byte write support

2014-07-18T13:51:19+00:00

commit f92fca0060fc4dc9227342d0072d75df98c1e5a5 upstream.

Move the first command byte write into advance_transaction() so that all
EC register accesses that can affect the command processing state machine
can happen in this asynchronous state machine advancement function.

The advance_transaction() function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
 1. The first command byte can be written in the interrupt context;
 2. The command completion waiter can also be used to wait the first command
    byte's timeout;
 3. In BURST mode, the follow-up command bytes can be written in the
    interrupt context directly, so that it doesn't need to return to the
    task context. Returning to the task context reduces the throughput of
    the BURST mode and in the worst cases where the system workload is very
    high, this leads to the hardware driven automatic BURST mode exit.

In order not to increase memory consumption, convert 'done' into 'flags'
to contain multiple indications:
 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
    indicating the completion of the command transaction.
 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
    command byte. A new command can utilize this flag to compete for the
    right of accessing the underlying hardware. There is a follow-up bug
    fix that has utilized this new flag.

The 2 flags are important because it also reflects a key concept of IO
programs' design used in the system softwares. Normally an IO program
running in the kernel should first be implemented in the asynchronous way.
And the 2 flags are the most common way to implement its synchronous
operations on top of the asynchronous operations:
1. POLL: This flag can be used to block until the asynchronous operations
         can happen.
2. COMPLETE: This flag can be used to block until the asynchronous
             operations have completed.
By constructing code cleanly in this way, many difficult problems can be
solved smoothly.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams 
Reported-and-tested-by: Hans de Goede 
Reported-by: Barton Xu 
Tested-by: Steffen Weber 
Tested-by: Arthur Chen 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby