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 <benjamin.tissoires@redhat.com>
Acked-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(Correct a wrong macro usage.)
This patch simplies the code by merging some redundant code.
No functional changes.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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: 23de5d9ef2
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 <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 <jarkko.nikula@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 <rafael.j.wysocki@intel.com>
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 <richard.musil@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: 3.11+ <stable@vger.kernel.org> # 3.11+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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 <shuah.kh@samsung.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* 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
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 <tianyu.lan@intel.com>
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and
<acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h>
inclusions and remove some inclusions of those files that aren't
necessary.
First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set,
<linux/acpi.h> includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.
Second, there are ordering dependencies between those files that always
have to be met. Namely, it is required that <acpi/acpi_bus.h> be included
prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the
latter depends on are always there. And <acpi/acpi.h> which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds. That also is taken care of including
<linux/acpi.h> as appropriate.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Input layer provides input_set_capability() to set input device's event
related bits. This patch is to use it to replace origin code.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is quite some time that this one has been deprecated.
Get rid of it.
Should some really important user be overseen, it may be reverted and
the userspace program worked on first, but it is time to do something
to get rid of this old stuff...
Signed-off-by: Thomas Renninger <trenn@suse.de>
Acked-by: Matthew Garrett <matthew.garrett@nebula.com>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull VFS updates from Al Viro,
Misc cleanups all over the place, mainly wrt /proc interfaces (switch
create_proc_entry to proc_create(), get rid of the deprecated
create_proc_read_entry() in favor of using proc_create_data() and
seq_file etc).
7kloc removed.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits)
don't bother with deferred freeing of fdtables
proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h
proc: Make the PROC_I() and PDE() macros internal to procfs
proc: Supply a function to remove a proc entry by PDE
take cgroup_open() and cpuset_open() to fs/proc/base.c
ppc: Clean up scanlog
ppc: Clean up rtas_flash driver somewhat
hostap: proc: Use remove_proc_subtree()
drm: proc: Use remove_proc_subtree()
drm: proc: Use minor->index to label things, not PDE->name
drm: Constify drm_proc_list[]
zoran: Don't print proc_dir_entry data in debug
reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show()
proc: Supply an accessor for getting the data from a PDE's parent
airo: Use remove_proc_subtree()
rtl8192u: Don't need to save device proc dir PDE
rtl8187se: Use a dir under /proc/net/r8180/
proc: Add proc_mkdir_data()
proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h}
proc: Move PDE_NET() to fs/proc/proc_net.c
...
The only part of proc_dir_entry the code outside of fs/proc
really cares about is PDE(inode)->data. Provide a helper
for that; static inline for now, eventually will be moved
to fs/proc, along with the knowledge of struct proc_dir_entry
layout.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
This patch fixes following compiler warnings when build via make W=1:
drivers/acpi/button.c:220:5: warning: no previous prototype for ‘acpi_lid_notifier_register’ [-Wmissing-prototypes]
drivers/acpi/button.c:226:5: warning: no previous prototype for ‘acpi_lid_notifier_unregister’ [-Wmissing-prototypes]
drivers/acpi/button.c:232:5: warning: no previous prototype for ‘acpi_lid_open’ [-Wmissing-prototypes]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The second argument of ACPI driver .remove() operation is only used
by the ACPI processor driver and the value passed to that driver
through it is always available from the given struct acpi_device
object's removal_type field. For this reason, the second ACPI driver
.remove() argument is in fact useless, so drop it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jiang Liu <jiang.liu@huawei.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
According to compiler warnings, several suspend/resume functions
in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add
#ifdefs to prevent them from being built in that case.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Make the ACPI button driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
If a button device had already been enabled to wake up the system
from sleep states before the button driver saw it, the driver
shouldn't disable the device's wakeup capability when being detached
from the device.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The wakeup.run_wake_count ACPI device field is only used by the PCI
runtime PM code to "protect" devices from being prepared for
generating wakeup signals more than once in a row. However, it
really doesn't provide any protection, because (1) all of the
functions it is supposed to protect use their own reference counters
effectively ensuring that the device will be set up for generating
wakeup signals just once and (2) the PCI runtime PM code uses
wakeup.run_wake_count in a racy way, since nothing prevents
acpi_dev_run_wake() from being called concurrently from two different
threads for the same device.
Remove the wakeup.run_wake_count ACPI device field which is
unnecessary, confusing and used in a wrong way.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Since ACPI buttons and lids can be configured to wake up the system
from sleep states, report wakeup events from these devices.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
There are ACPI devices (buttons and the laptop lid) that can wake up
the system from sleep states and have no "physical" companion
devices. The ACPI subsystem uses two flags, wakeup.state.enabled and
wakeup.flags.always_enabled, for handling those devices, but they
are not accessible through the standard device wakeup infrastructure.
User space can only control them via the /proc/acpi/wakeup interface
that is not really convenient (e.g. the way in which devices are
enabled to wake up the system is not portable between different
systems, because it requires one to know the devices' "names" used in
the system's ACPI tables).
To address this problem, use standard device wakeup flags instead of
the special ACPI flags for handling those devices. In particular,
use device_set_wakeup_capable() to mark the ACPI wakeup devices
during initialization and use device_set_wakeup_enable() to allow
or disallow them to wake up the system from sleep states. Rework
the /proc/acpi/wakeup interface to take these changes into account.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Benjamin Tissoires
Lv Zheng
Jarkko Nikula
Rafael J. Wysocki
Lan Tianyu
Shuah Khan
Thomas Renninger
Linus Torvalds
Al Viro
Andy Shevchenko
Mika Westerberg
Rafael J. Wysocki
Zhang Rui