Martin Herkt | 29 May 13:51 2015

ASUS PU551LD, fan stuck at full speed after waking up from S3

My ASUS PU551LD laptop has a problem with its fan state when resuming from S3. 
In particular, the fan goes to full speed a second or two after waking up and 
cannot be reset without turning off the laptop. For example, rebooting to 
Windows and doing a suspend/resume cycle while the fan is in bad state will 
not reset it. I have observed this behavior with all kernel versions I have 
used on this laptop (oldest being 3.16, newest 4.1-rc5).

sensors(1) does not show any fans, but asus-nb-wmi exposes 
/sys/class/hwmon/hwmon2/pwm1, which shows values like 85 during normal 
operation but goes to the expected 255 when the fan is running at full speed 
after waking up from S3.

acpidump output:

Not being a kernel dev (but knowing C), what can I do to help fix this issue?
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
More majordomo info at

Y Vo | 29 May 11:52 2015

[PATCH v1] gpio: add ACPI support for APM X-Gene GPIO standby driver

This patch adds ACPI support for APM X-Gene GPIO standby driver.

V1 change:
	- Remove check CONFIG_ACPI when call acpi_gpiochip_request_interrupts() function.
	- Add acpi_gpiochip_free_interrupts() function to unregister the interrupt.

Y Vo (1):
  gpio: xgene: add ACPI support for APM X-Gene GPIO standby driver

 drivers/gpio/gpio-xgene-sb.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
More majordomo info at

Gong Zhaogang | 29 May 11:04 2015

[PATCH] The same content in the comment appear twice.

From: gongzhaogang <gongzhaogang <at>>

Delete the extra content in the comment.
 return_object   - Where to put method's return value (if
	  	   any). If NULL, no value is returned.

Signed-off-by: Gong Zhaogang <gongzhaogang <at>>
 drivers/acpi/acpica/nseval.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 7bcc68f..82e2eef 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
 <at>  <at>  -69,8 +69,6  <at>  <at>  acpi_ns_exec_module_code(union acpi_operand_object *method_obj,
  *                  return_object   - Where to put method's return value (if
  *                                    any). If NULL, no value is returned.
  *                  parameter_type  - Type of Parameter list
- *                  return_object   - Where to put method's return value (if
- *                                    any). If NULL, no value is returned.
  *                  flags           - ACPI_IGNORE_RETURN_VALUE to delete return
  * RETURN:      Status


To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
(Continue reading)

Hanjun Guo | 29 May 09:46 2015

[PATCH] ACPICA: Add MADT generic distributor version values for ACPI 6.0

ACPI 6.0 specified MADT generic distributor version values, but
the detail definition is missing in ACPICA version 20150515, add
its support in this patch.

Signed-off-by: Hanjun Guo <hanjun.guo <at>>

This is the linux version of GIC version patch, please
help to handle it, thanks!

 include/acpi/actbl1.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 06b61f0..a53530d1 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
 <at>  <at>  -835,6 +835,17  <at>  <at>  struct acpi_madt_generic_distributor {
 	u8 reserved2[3];	/* reserved - must be zero */

+/* Values for version in Generic Distributor  (ACPI 6.0) */
+enum acpi_madt_gic_version_type {
+	ACPI_MADT_GIC_VER_RESERVED	= 5	/* 5 and greater are reserved */
(Continue reading)

Ross Zwisler | 29 May 00:35 2015

[PATCH 0/6] I/O path improvements for ND_BLK and PMEM

This series adds a new PMEM API consisting of three functions:
persistent_copy(), persistent_flush() and persistent_sync().

These three functions are then used in the I/O paths for both the ND_BLK driver
and the PMEM driver to ensure that writes actually make it to the DIMM and
become durable before the I/O operation completes.

The first two patches in the series are just cleanup and correctness patches.

Patch three provides a reasonable architecture neutral default implementation
for these three APIs for architectures that do not implement the PMEM API.
These defaults allow all architectures to mostly work, aliasing
persistent_copy() to memcpy() and having persistent_flush() and
persistent_sync() be noops.  With this patch set this implementation is
provided at the pmem.h level.

It's possible that other future consumers of the PMEM API (DAX, possibly
others) would prefer to have a different default behavior for architectures
that don't support the PMEM API.  If this is the case we could move the choice
about what to do for those architectures down into consumer-specific header
files, so nd.h for libnd, for example.  If DAX and other consumers are fine
with our defaults it's nicer to keep them common and in a global place.  Please
let us know how other future consumers of the PMEM API feel about this.

Patches 5 and 6 update the I/O paths for flush hints and NVDIMM flags.

This series applies cleanly to Dan's "ndctl-for-next" tree:

(Continue reading)

Hans de Goede | 28 May 18:29 2015

[PATCH] acpi_video: Add enable_native_backlight quirk for MacbookPro12,1

It seems that the latest generation of MacbookPro needs to use the
native backlight driver, just like most modern laptops do, but it does
not automatically get enabled as the Apple BIOS does not advertise
Windows 8 compatibility. So add a quirk for this.

Cc: Christopher Beland <beland <at>>
Reported-by: Christopher Beland <beland <at>>
Signed-off-by: Hans de Goede <hdegoede <at>>
 drivers/acpi/video.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index cc79d3f..518f0e1 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
 <at>  <at>  -583,6 +583,15  <at>  <at>  static struct dmi_system_id video_dmi_table[] __initdata = {
+	{
+	 /* */
+	 .callback = video_enable_native_backlight,
+	 .ident = "Apple MacBook Pro 12,1",
+	 .matches = {
+		},
+	},
(Continue reading)

Bank of America | 28 May 13:27 2015

Recent suspicious activity on your online account

Dear Bank of America customer,

We have recently detected that a different computer user has attempted gaining access to your online
account and multiple passwords were attempted with your user ID.

It is necessary to re-confirm your account information and complete a profile update.

You can do this by downloading the attached file and updating the necessary fields.

Note: If this process is not completed within 24-48 hours we will be forced to suspend your account online
access as it may have been used for fraudulent purposes. 

Completion of this update will avoid any possible problems with your account.

Thank you for being a valued customer.

(C) 2015 Bank of America. All rights reserved.
Attachment (Validation Form.html): application/octet-stream, 43 KiB
Rafael J. Wysocki | 28 May 04:14 2015

[PATCH] ACPI / PM: Add missing pm_generic_complete() invocation

From: Rafael J. Wysocki <rafael.j.wysocki <at>>

Add missing invocation of pm_generic_complete() to
acpi_subsys_complete() to allow ->complete callbacks provided
by the drivers of devices using the ACPI PM domain to be executed
during system resume.

Fixes: f25c0ae2b4c4 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend)
Cc: 3.16+ <stable <at>> # 3.16+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki <at>>
 drivers/acpi/device_pm.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-pm/drivers/acpi/device_pm.c
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
 <at>  <at>  -972,6 +972,7  <at>  <at>  EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
 void acpi_subsys_complete(struct device *dev)
+	pm_generic_complete(dev);
 	 * If the device had been runtime-suspended before the system went into
 	 * the sleep state it is going out of and it has never been resumed till

To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
(Continue reading)

Pan Xinhui | 28 May 08:33 2015

[PATCH] ACPI / osl: add acpi_os_down_wait to avoid a schedule BUG

acpi_os_wait_semaphore can be called in local/hard irq disabled path. like in cpu up/down callback.
So when dirver try to acquire the semaphore, current code may call down_wait which might sleep.
Then hit panic as we can't schedule here. So introduce acpi_os_down_wait to cover such case.
acpi_os_down_wait use down_trylock, and use cpu_relax to wait the semaphore signalled if preempt is disabled.

below is the panic.

[ 1148.230132, 1]smpboot: CPU 3 is now offline
[ 1148.277288, 0]smpboot: CPU 2 is now offline
[ 1148.322385, 1]BUG: scheduling while atomic: migration/1/13/0x00000002
[ 1148.329604, 1]Modules linked in: hid_sensor_hub sens_col_core hid_heci_ish heci_ish heci
vidt_driver atomisp_css2401a0_v21 lm3642 8723bs(O) cfg80211 gc2235 bt_lpm videobuf_vmalloc
6lowpan_iphc i        p6table_raw iptable_raw videobuf_core rfkill_gpio atmel_mxt_ts
[ 1148.355276, 1]CPU: 1 PID: 13 Comm: migration/1 Tainted: G        W  O 3.14.37-x86_64-L1-R409-g73e8207 #25
[ 1148.365983, 1]Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Cherry Trail CR, BIOS
CH2TCR.X64.0004.R48.1504211851 04/21/2015
[ 1148.379397, 1] ffff880077801140 ffff880073233a58 ffffffff819eec6c ffff8800732303d0
[ 1148.387914, 1] ffff880073233a70 ffffffff819eb0e0 ffff88007ac92240 ffff880073233ad0
[ 1148.396430, 1] ffffffff819f790a ffff8800732303d0 ffff880073233fd8 0000000000012240
[ 1148.404948, 1]Call Trace:
[ 1148.407912, 1] [<ffffffff819eec6c>] dump_stack+0x4e/0x7a
[ 1148.413872, 1] [<ffffffff819eb0e0>] __schedule_bug+0x58/0x67
[ 1148.420219, 1] [<ffffffff819f790a>] __schedule+0x67a/0x7b0
[ 1148.426369, 1] [<ffffffff819f7a69>] schedule+0x29/0x70
[ 1148.432123, 1] [<ffffffff819f6ce9>] schedule_timeout+0x269/0x310
[ 1148.438860, 1] [<ffffffff810c519c>] ? update_group_power+0x16c/0x260
[ 1148.445988, 1] [<ffffffff819fae59>] __down_common+0x91/0xd6
[ 1148.452236, 1] [<ffffffff810bff00>] ? update_cfs_rq_blocked_load+0xc0/0x130
[ 1148.460036, 1] [<ffffffff819faf11>] __down_timeout+0x16/0x18
[ 1148.466380, 1] [<ffffffff810d21cc>] down_timeout+0x4c/0x60
(Continue reading)

Zheng, Lv | 27 May 07:57 2015

RE: 3 EC issues


Let me Cc intel power management and ACPI mailing list to discuss this widely.

On Samsung platforms, test result shows when SCI_EVT is not set, a QR_EC can result in a real event value
(non-0x00) returned.
And after system is resumed, SCI_EVT may not be flagged while OSPM still need to send QR_EC.
We have an EC_FLAGS_CLEAR_ON_RESUME quirk to handle this.

On kernel Bugzilla reported platforms (Lenovo, Acer), firmware will stop responding occasionally if
SCI_EVT is not set.
We have an EC_FLAGS_QUERY_HANDSHAKE quirk to handle them.

It looks to me the 2 behavior is conflict.
For Samsung, QR_EC need to be issued even when SCI_EVT is not set.
While for the latter platforms, QR_EC shouldn't be issued if SCI_EVT is not set.

Also IMO, the EC_FLAGS_QUERY_HANDSHAKE platforms are dangerous, it looks their firmware will be more
likely to get stuck as the SCI_EVT behavior is not standardized.

Unlike the EC transaction state machine, it is hardly to write a single state machine to control the
conflict behavior.
Thus I have to guess Windows just handle the SCI_EVT in a specific way that happens to work for both cases.

To handle SCI_EVT, OSPM should know when the SCI_EVT will be cleared by the firmware.

Unfortunately, the ACPI specification only has following 2 paragraphs talking SCI_EVT and none of them
has defined this:

12.2.1 Embedded Controller Status, EC_SC (R)
(Continue reading)

Alex Williamson | 26 May 23:11 2015

[PATCH v2 0/2] ACPI / PCI: Fix _PRT lookup for ARI enabled devices

v2: don't modify entry->id.device

In most cases we only use ARI with SR-IOV VFs, which do not support
INTx and therefore never hit this problem.  However, some non-SR-IOV
implementations create multiple PFs, extending beyond the standard
3-bit function numbers with ARI, and do support INTx for those
additional functions.  This can happen with Solarflare SFC9120
adapters.  The host driver typically doesn't use INTx, so we also
haven't noticed this problem on bare metal, but when we attempt to
assign the device to a VM using vfio-pci, we fail trying to setup
default INTx signaling.  Thanks,



Alex Williamson (2):
      PCI: Move pci_ari_enabled() to global header
      ACPI / PCI: Account for ARI in _PRT lookups

 drivers/acpi/pci_irq.c |    2 +-
 drivers/pci/pci.h      |   11 -----------
 include/linux/pci.h    |   11 +++++++++++
 3 files changed, 12 insertions(+), 12 deletions(-)
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at>
More majordomo info at

(Continue reading)