linux/drivers/acpi/button.c, branch v4.8

ACPI / button: remove pointer to old lid_sysfs on unbind

2016-08-02T23:27:20Z

When we removed the procfs dir on error or if the driver is unbound, the two variables acpi_lid_dir and acpi_button_dir were not reset. On the next rebind, those static variables were not null and we couldn't re-register the device again. Signed-off-by: Benjamin Tissoires Acked-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / button: Add quirks for initial lid state notification

2016-06-22T00:10:17Z

Linux userspace (systemd-logind) keeps on rechecking lid state when the lid state is closed. If it failed to update the lid state to open after boot/resume, the system suspending right after the boot/resume could be resulted. Graphics drivers also use the lid notifications to implment MODESET_ON_LID_OPEN option. Before the situation is improved from the userspace and from the graphics driver, users can simply configure ACPI button driver to send initial "open" lid state using button.lid_init_state=open to avoid such kind of issues. And our ultimate target should be making button.lid_init_state=ignore the default behavior. This patch implements the 2 options and keep the old behavior (button.lid_init_state=method). Link: https://lkml.org/2016/3/7/460 Link: https://github.com/systemd/systemd/issues/2087 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / button: Refactor functions to eliminate redundant code

2016-06-22T00:10:15Z

(Correct a wrong macro usage.) This patch simplies the code by merging some redundant code. No functional changes. Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / button: Remove initial lid state notification

2016-06-22T00:10:14Z

The _LID control method's initial returning value is not reliable. The _LID control method is described to return the "current" lid state. However the word of "current" has ambiguity, many BIOSen return the lid state upon the last lid notification instead of returning the lid state upon the last _LID evaluation. There won't be difference when the _LID control method is evaluated during the runtime, the problem is its initial returning value. When the BIOSen implement this control method with cached value, the initial returning value is likely not reliable. There are simply so many examples retuning "close" as initial lid state (Link 1), sending this state to the userspace causes suspending right after booting/resuming. Since the lid state is implemented by the BIOSen, the kernel lid driver has no idea how it can be correct, this patch stops sending the initial lid state to the userspace to try to avoid sending the wrong lid state to the userspace to trigger such kind of wrong suspending. This actually reverts the following commit introduced for fixing a Novell bug: Commit: 23de5d9ef2a4bbc4f733f58311bcb7cf6239c813 Subject: ACPI: button: send initial lid state after add and resume Link: https://bugzilla.kernel.org/show_bug.cgi?id=89211 Link: https://bugzilla.kernel.org/show_bug.cgi?id=106151 Link: https://bugzilla.kernel.org/show_bug.cgi?id=106941 Link: https://bugzilla.novell.com/show_bug.cgi?id=326814 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI: Remove FSF mailing addresses

2015-07-08T00:27:32Z

There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula Signed-off-by: Rafael J. Wysocki

ACPI / button: Do not propagate wakeup-from-suspend events

2014-07-22T22:59:04Z

During system suspend mark ACPI buttons (other than the lid) as "suspended" and if in that state, report wakeup events on button events, but do not propagate those events up the stack. This prevents systems from being turned off after a button-triggered wakeup from the "freeze" sleep state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77611 Tested-on: Acer Aspire S5, Toshiba Portege R500 Signed-off-by: Rafael J. Wysocki

ACPI / button: Add ACPI Button event via netlink routine

2014-03-19T01:06:15Z

Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface) removed ACPI Button event which originally was sent to userspace via /proc/acpi/event. This caused ACPI shutdown regression on gentoo in VirtualBox. Now ACPI events are sent to userspace via netlink, so add ACPI Button event back via netlink routine. References: https://bugzilla.kernel.org/show_bug.cgi?id=71721 Reported-and-tested-by: Richard Musil Signed-off-by: Lan Tianyu Cc: 3.11+ # 3.11+ Signed-off-by: Rafael J. Wysocki

ACPI / button: fix button driver compile error when CONFIG_PM_SLEEP is undefined

2014-02-13T14:13:44Z

The ACPI button driver defines acpi_button_resume() when CONFIG_PM_SLEEP is defined. This results in the following compile error when CONFIG_PM_SLEEP is undefined: drivers/acpi/button.c:85:8: error: ‘acpi_button_resume’ undeclared here (not in a function) Signed-off-by: Shuah Khan Signed-off-by: Rafael J. Wysocki

Merge branches 'acpi-gpe', 'acpi-video', 'acpi-thermal', 'acpi-processor', 'acpi-sleep'

2014-01-12T22:46:55Z

* acpi-gpe: ACPI / EC: disable GPE before removing GPE handler ACPI / Button: Fix enabling button GPEs twice * acpi-video: ACPI: Blacklist Win8 OSI for some HP laptop 2013 models ACPI / video: Fix typo in video_detect.c * acpi-thermal: ACPI / thermal: remove const from thermal_zone_device_ops declaration * acpi-processor: ACPI / scan: bail out early if failed to parse APIC ID for CPU * acpi-sleep: ACPI / sleep: remove panic in case hardware has changed after S4

ACPI / Button: Fix enabling button GPEs twice

2013-12-19T14:07:00Z

Button GPEs have been enabled in the acpi_wake_device_init() during boot and the button driver enables them for the second time. Consequently, it is necessary to do # echo disable > /sys/firmware/acpi/interrupts/gpeXXX twice in a row to disable those GPEs via sysfs. This patch is to remove the GPE enabling code from the button driver to avoid the problem. Signed-off-by: Lan Tianyu [rjw: Changelog] Signed-off-by: Rafael J. Wysocki