summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* ACPI: Always check if _PRW is present before trying to evaluate itRafael J. Wysocki2011-01-121-2/+7
| | | | | | | | | | | | Before evaluating _PRW for devices that are reported as inactive or not present by their _STA control methods we should check if those methods are actually present (otherwise the evaulation of _PRW will obviously fail and a scary message will be printed unnecessarily). Reported-by: Andreas Mohr <andi@lisas.de> Reported-by: Maciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Check status of power resources under mutexesRafael J. Wysocki2011-01-121-13/+20
| | | | | | | | | | | It certainly is not a good idea to execute _ON or _OFF and _STA for the same power resource at the same time which may happen in some circumstances in theory. To prevent that from happening, read the power state of each power resource under its mutex, as that will prevent the state from being changed at the same time. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI / PM: Rename acpi_power_off_device()Rafael J. Wysocki2011-01-121-4/+3
| | | | | | | | Rename acpi_power_off_device() to acpi_power_off() in analogy with acpi_power_on(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* Merge branch 'kconfig-text' into releaseLen Brown2011-01-121-1/+0
|\
| * ACPI: update CONFIG_ACPI_PROCFS descriptionZhang Rui2011-01-121-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update CONFIG_ACPI_PROCFS description because the processor, video and thermal zone procfs I/F have been removed. Some ACPI drivers, e.g. button, have their procfs I/F always built in, because we don't have sysfs I/F replacement at the moment. But once we finish developing the sysfs I/F for these driver, we need CONFIG_ACPI_PROCFS to enabled/disable the corresponding procfs I/F. So just updating the description rather than removing this option, although there is no procfs I/F depends on it for now. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'ipmi' into releaseLen Brown2011-01-125-4/+580
|\|
| * IPMI/ACPI: Add the IPMI opregion driver to enable ACPI to access BMC controllerZhao Yakui2010-12-143-0/+537
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI 4.0 spec adds the ACPI IPMI opregion, which means that the ACPI AML code can also communicate with the BMC controller. This is to install the ACPI IPMI opregion and enable the ACPI to access the BMC controller through the IPMI message. It will create IPMI user interface for every IPMI device detected in ACPI namespace and install the corresponding IPMI opregion space handler. Then it can enable ACPI to access the BMC controller through the IPMI message. The following describes how to process the IPMI request in IPMI space handler: 1. format the IPMI message based on the request in AML code. IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE IPMI net function & command IPMI message payload 2. send the IPMI message by using the function of ipmi_request_settime 3. wait for the completion of IPMI message. It can be done in different routes: One is in handled in IPMI user recv callback function. Another is handled in timeout function. 4. format the IPMI response and return it to ACPI AML code. At the same time it also addes the module dependency. The ACPI IPMI opregion will depend on the IPMI subsystem. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * IPMI: Add one interface to get more info of low-level IPMI deviceZhao Yakui2010-12-142-4/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IPMI smi_watcher will be used to catch the IPMI interface as they come or go. In order to communicate with the correct IPMI device, it should be confirmed whether it is what we wanted especially on the system with multiple IPMI devices. But the new_smi callback function of smi_watcher provides very limited info(only the interface number and dev pointer) and there is no detailed info about the low level interface. For example: which mechansim registers the IPMI interface(ACPI, PCI, DMI and so on). This is to add one interface that can get more info of low-level IPMI device. For example: the ACPI device handle will be returned for the pnp_acpi IPMI device. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'apei' into releaseLen Brown2011-01-123-88/+656
|\ \
| * | ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type supportHuang Ying2011-01-121-84/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generic Hardware Error Source provides a way to report platform hardware errors (such as that from chipset). It works in so called "Firmware First" mode, that is, hardware errors are reported to firmware firstly, then reported to Linux by firmware. This way, some non-standard hardware error registers or non-standard hardware link can be checked by firmware to produce more valuable hardware error information for Linux. This patch adds POLL/IRQ/NMI notification types support. Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that. Known issue: - Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via irq_work or make printk NMI-safe. v2: - adjust printk format per comments. Signed-off-by: Huang Ying <ying.huang@intel.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI, APEI, Report GHES error information via printkHuang Ying2010-12-131-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | printk is one of the methods to report hardware errors to user space. This patch implements hardware error reporting for GHES via printk. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI, APEI, Add APEI generic error status printing supportHuang Ying2010-12-132-0/+313
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In APEI, Hardware error information reported by firmware to Linux kernel is in the data structure of APEI generic error status (struct acpi_hes_generic_status). While now printk is used by Linux kernel to report hardware error information to user space. So, this patch adds printing support for the data structure, so that the corresponding hardware error information can be reported to user space via printk. PCIe AER information printing is not implemented yet. Will refactor the original PCIe AER information printing code to avoid code duplicating. The output format is as follow: <error record> := APEI generic hardware error status severity: <integer>, <severity string> section: <integer>, severity: <integer>, <severity string> flags: <integer> <section flags strings> fru_id: <uuid string> fru_text: <string> section_type: <section type string> <section data> <severity string>* := recoverable | fatal | corrected | info <section flags strings># := [primary][, containment warning][, reset][, threshold exceeded]\ [, resource not accessible][, latent error] <section type string> := generic processor error | memory error | \ PCIe error | unknown, <uuid string> <section data> := <generic processor section data> | <memory section data> | \ <pcie section data> | <null> <generic processor section data> := [processor_type: <integer>, <proc type string>] [processor_isa: <integer>, <proc isa string>] [error_type: <integer> <proc error type strings>] [operation: <integer>, <proc operation string>] [flags: <integer> <proc flags strings>] [level: <integer>] [version_info: <integer>] [processor_id: <integer>] [target_address: <integer>] [requestor_id: <integer>] [responder_id: <integer>] [IP: <integer>] <proc type string>* := IA32/X64 | IA64 <proc isa string>* := IA32 | IA64 | X64 <processor error type strings># := [cache error][, TLB error][, bus error][, micro-architectural error] <proc operation string>* := unknown or generic | data read | data write | \ instruction execution <proc flags strings># := [restartable][, precise IP][, overflow][, corrected] <memory section data> := [error_status: <integer>] [physical_address: <integer>] [physical_address_mask: <integer>] [node: <integer>] [card: <integer>] [module: <integer>] [bank: <integer>] [device: <integer>] [row: <integer>] [column: <integer>] [bit_position: <integer>] [requestor_id: <integer>] [responder_id: <integer>] [target_id: <integer>] [error_type: <integer>, <mem error type string>] <mem error type string>* := unknown | no error | single-bit ECC | multi-bit ECC | \ single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ target abort | parity error | watchdog timeout | invalid address | \ mirror Broken | memory sparing | scrub corrected error | \ scrub uncorrected error <pcie section data> := [port_type: <integer>, <pcie port type string>] [version: <integer>.<integer>] [command: <integer>, status: <integer>] [device_id: <integer>:<integer>:<integer>.<integer> slot: <integer> secondary_bus: <integer> vendor_id: <integer>, device_id: <integer> class_code: <integer>] [serial number: <integer>, <integer>] [bridge: secondary_status: <integer>, control: <integer>] <pcie port type string>* := PCIe end point | legacy PCI end point | \ unknown | unknown | root port | upstream switch port | \ downstream switch port | PCIe to PCI/PCI-X bridge | \ PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ root complex event collector Where, [] designate corresponding content is optional All <field string> description with * has the following format: field: <integer>, <field string> Where value of <integer> should be the position of "string" in <field string> description. Otherwise, <field string> will be "unknown". All <field strings> description with # has the following format: field: <integer> <field strings> Where each string in <fields strings> corresponding to one set bit of <integer>. The bit position is the position of "string" in <field strings> description. For more detailed explanation of every field, please refer to UEFI specification version 2.3 or later, section Appendix N: Common Platform Error Record. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'acpi-video' into releaseLen Brown2011-01-124-141/+7
|\ \
| * | ACPI video: check cap._DDC flag before getting EDIDZhang Rui2010-12-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | cap._DDC is defined but never used. Check this flag now and don't try to get EDID for video output devices with this flag cleared. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI video: remove output switching controlZhang Rui2010-12-144-141/+4
| |/ | | | | | | | | | | | | | | | | | | | | Remove the ACPI video output switching control as it never works. With the patch applied, ACPI video driver still catches the video output notification, but it does nothing but raises the notification to userspace. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'throttling' into releaseLen Brown2011-01-122-3/+78
|\ \
| * | ACPI: Reevaluate whether the T-state is supported or not after cpu is ↵Zhao Yakui2011-01-102-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | online/offline After one CPU is offlined, it is unnecessary to switch T-state for it. So it will be better that the throttling is disabled after the cpu is offline. At the same time after one cpu is online, we should check whether the T-state is supported and then set the corresponding T-state flag. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Check the returned value of set_cpus_allowed_ptr before T-state operationZhao Yakui2011-01-101-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now before it executes the T-state operation on one CPU, it will try to migrate to the target CPU. Especially this is required on the system that uses the MSR_IA32_THERMAL_CONTROL register to switch T-state. But unfortunately it doesn't check whether the migration is successful or not. In such case we will get/set the incorrect T-state on the offline CPU as it fails in the migration to the offline CPU. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'thermal' into releaseLen Brown2011-01-122-1/+103
|\ \ \
| * | | thermal: Add event notification to thermal frameworkR.Durgadoss2011-01-122-1/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds event notification support to the generic thermal sysfs framework in the kernel. The notification is in the form of a netlink event. Signed-off-by: R.Durgadoss <durgadoss.r@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | Merge branch 'procfs-cleanup' into releaseLen Brown2011-01-126-193/+9
|\ \ \ \
| * | | | ACPI: delete CONFIG_ACPI_PROCFS_POWER and power procfs I/F in 2.6.39Zhang Rui2011-01-124-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sysfs I/F for ACPI power devices, including AC and Battery, has been working in upstream kenrel since 2.6.24, Sep 2007. In 2.6.37, we made the sysfs I/F always built in and this option disabled by default. Now, we plan to remove this option and the ACPI power procfs interface in 2.6.39. First, update the feature-removal-schedule to announce this change. Second, add runtime warnings in ACPI AC/Battery/SBS driver, so that users will notice this change even if "make oldconfig" is used. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | ACPI processor: remove processor throttling control procfs I/FZhang Rui2010-12-143-192/+1
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove deprecated ACPI process procfs I/F for throttling control. This is because the t-state control should only be done in kernel, when system is in a overheating state. Now users can only change the processor t-state indirectly, by poking the cooling device sysfs I/F of the processor. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | Merge branch 'pnp' into releaseLen Brown2011-01-125-14/+13
|\ \ \ \
| * | | | PNP: Set up pnp_debug via module and not via boot param.Thomas Renninger2010-10-271-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cleanup only, no functional change (pnp.debug can be enabled and disabled at runtime, but that's not a real enhancement). This one depends on another PNP cleanup patch: PNP: Compile all pnp built-in stuff in one module namespace Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | PNP: Compile all pnp built-in stuff in one module namespaceThomas Renninger2010-10-274-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is cleanup mostly, nothing urgent. I came up with it when looking at dynamic debug which can enable pr_debug messages at runtime or boot param for a specific module. Advantages: - Any pnp code can make use of the moduleparam.h interface, the modules will show up as pnp.param. - Passing pnp.ddebug as kernel boot param will enable all pnp debug messages with my previous patch and CONFIG_DYNAMIC_DEBUG enabled. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | | Merge branch 'bugzilla-15100' into releaseLen Brown2011-01-122-28/+72
|\ \ \ \ \
| * | | | | PNP / ACPI: Use DEVICE_ACPI_HANDLE() for device ACPI handle accessRafael J. Wysocki2011-01-112-28/+72
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PNP ACPI driver squirrels the ACPI handles of PNP devices' ACPI companions, but this isn't correct, because those handles should be accessed using the DEVICE_ACPI_HANDLE() macro operating on struct device objects. Using DEVICE_ACPI_HANDLE() in the PNP ACPI driver instead of the driver's own copies of the ACPI handles allows us to avoid a problem with docking stations where a machine docked before suspend to RAM and undocked while suspended crashes during the subsequent resume (in that case the ACPI companion of the PNP device in question doesn't exist any more while the device is being resumed). It also allows us to avoid the problem where suspend to RAM fails when the machine was undocked while suspended before (again, the ACPI companion of the PNP device is not present any more while it is being suspended). This change doesn't fix all of the the PNP ACPI driver's problems with PNP devices in docking stations (generally speaking, the driver has no idea that devices can come and go and doesn't even attempt to handle such events), but at least it makes suspend work for the users of docking stations who don't use the PNP devices located in there. References: https://bugzilla.kernel.org/show_bug.cgi?id=15100 Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | | Merge branch 'suspend-ioremap-cache' into releaseLen Brown2011-01-125-7/+158
|\ \ \ \ \
| * | | | | ACPI: Use ioremap_cache()Len Brown2011-01-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although the temporary boot-time ACPI table mappings were set up with CPU caching enabled, the permanent table mappings and AML run-time region memory accesses were set up with ioremap(), which on x86 is a synonym for ioremap_nocache(). Changing this to ioremap_cache() improves performance as seen when accessing the tables via acpidump, or /sys/firmware/acpi/tables. It should also improve AML run-time performance. No change on ia64. Reported-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
| * | | | | ACPI / PM: Make suspend_nvs_save() use acpi_os_map_memory()Rafael J. Wysocki2011-01-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the NVS memory region that suspend_nvs_save() attempts to map has been already mapped by acpi_os_map_memory(), so suspend_nvs_save() should better use acpi_os_map_memory() for mapping memory to avoid conflicts. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Update file information and the list of includes in nvs.cRafael J. Wysocki2011-01-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The file information and the list of include in drivers/acpi/nvs.c are outdated, so update them. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | PM / ACPI: Move NVS saving and restoring code to drivers/acpiRafael J. Wysocki2011-01-073-1/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The saving of the ACPI NVS area during hibernation and suspend and restoring it during the subsequent resume is entirely specific to ACPI, so move it to drivers/acpi and drop the CONFIG_SUSPEND_NVS configuration option which is redundant. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | PM: Fix oops in suspend/hibernate code related to failing ioremap()Jiri Slaby2011-01-071-3/+2
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When ioremap() fails (which might happen for some reason), we nicely oops in suspend_nvs_save() due to NULL dereference by memcpy() in there. Fail gracefully instead. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | | Merge branch 'wakeup-etc-rafael' into releaseLen Brown2011-01-127-83/+94
|\ \ \ \ \
| * | | | | ACPI / PM: Blacklist Averatec machine known to require acpi_sleep=nonvsRafael J. Wysocki2011-01-071-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently, Averatec AV1020-ED2 does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. References: https://bugzilla.kernel.org/show_bug.cgi?id=16396#c86 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Report wakeup events from buttonsRafael J. Wysocki2011-01-071-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | ACPI / PM: Drop special ACPI wakeup flagsRafael J. Wysocki2011-01-071-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drop special ACPI wakeup flags, wakeup.state.enabled and wakeup.flags.always_enabled, that aren't necessary any more after we've started to use standard device wakeup flags for handling ACPI wakeup devices. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Use device wakeup flags for handling ACPI wakeup devicesRafael J. Wysocki2011-01-074-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | | ACPI / PM: Do not enable multiple devices to wake up simultaneouslyRafael J. Wysocki2011-01-071-25/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a device is enabled to wake up the system from sleep states via /proc/acpi/wakeup and there are other devices associated with the same wakeup GPE, all of these devices are automatically enabled to wake up the system. This isn't correct, because the fact the GPE is shared need not imply that wakeup power has to be enabled for all the devices at the same time (i.e. it is possible that one device will have its wakeup power enabled and it will wake up the system from a sleep state if the shared wakeup GPE is enabled, while another device having its wakeup power disabled will not wake up the system even though the GPE is enabled). Rework acpi_system_write_wakeup_device() so that it only enables wakeup for one device at a time. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / ACPICA: Fix global lock acquisitionRafael J. Wysocki2011-01-071-39/+55
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two problems with the ACPICA's current implementation of the global lock acquisition. First, acpi_ev_global_lock_handler(), which in fact is an interface to the outside of the kernel, doesn't validate its input, so it only works correctly if the other side (i.e. the ACPI firmware) is fully specification-compliant (as far as the global lock is concerned). Unfortunately, that's known not to be the case on some systems (i.e. we get spurious global lock signaling interrupts without the pending flag set on some systems). Second, acpi_ev_global_lock_handler() attempts to acquire the global lock on behalf of a thread waiting for it without checking if there actually is such a thread. Both of these shortcomings need to be addressed to prevent all possible race conditions from happening. Rework acpi_ev_global_lock_handler() so that it doesn't try to acquire the global lock and make it signal the availability of the global lock to the waiting thread instead. Make sure that the availability of the global lock can only be signaled when there is a thread waiting for it and that it can't be signaled more than once in a row (to keep acpi_gbl_global_lock_semaphore in balance). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
* | | | | Merge branch 'power-resource' into releaseLen Brown2011-01-127-142/+169
|\ \ \ \ \
| * | | | | ACPI / PM: Drop acpi_power_nocheckRafael J. Wysocki2011-01-123-43/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since acpi_bus_set_power() should not use __acpi_bus_get_power() to update the device's device->power.state field before changing its power state (this may cause device->power.state to be inconsistent with the device power resources' reference counters), remove this call from it. In consequence, the acpi_power_nocheck variable is not necessary any more, so it can be dropped along with the DMI table used for setting that variable for HP Pavilion 05. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Drop acpi_bus_get_power()Rafael J. Wysocki2011-01-121-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are no more users of acpi_bus_get_power(), so it can be dropped. Moreover, it should be dropped, because it modifies the device->power.state field of an ACPI device without updating the reference counters of the device's power resources, which is wrong. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | Platform / x86: Make fujitsu_laptop use acpi_bus_update_power()Rafael J. Wysocki2011-01-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the new function acpi_bus_update_power(), which is safer than acpi_bus_get_power(), for getting device power state in acpi_fujitsu_add() and acpi_fujitsu_hotkey_add(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / Fan: Rework the handling of power resourcesRafael J. Wysocki2011-01-123-23/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the new function acpi_bus_update_power() for manipulating power resources used by ACPI fan devices, which allows them to be put into the right state during initialization and resume. Consequently, remove the flags.force_power_state field from struct acpi_device, which is not necessary any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Register power resource devices as soon as they are neededRafael J. Wysocki2011-01-121-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on the organization of the ACPI namespace, power resource device objects may generally be scanned after the "regular" device objects that they are referred from through _PRn. This, in turn, may cause acpi_bus_get_power_flags() to attempt to access them through acpi_bus_init_power() before they are registered (and initialized by acpi_power_driver). [This is not a theoretical issue, it actually happens for one PnP device on my testbed HP nx6325.] To fix this problem, make acpi_bus_get_power_flags() attempt to register power resource devices as soon as they have been found in the _PRn output for any other devices. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Register acpi_power_driver earlyRafael J. Wysocki2011-01-122-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI device driver used for handling power resources, acpi_power_driver, creates a struct acpi_power_resource object for each ACPI device representing a power resource. These objects are then used when setting and reading the power states of devices using the corresponding power resources. Unfortunately, acpi_power_driver is registered after acpi_scan_init() that may add devices using the power resources before acpi_power_driver has a chance to create struct acpi_power_resource objects for them (specifically, the power resources may be referred to during the scanning process through acpi_bus_get_power() before they have been initialized). As the first step towards fixing this issue, move the registration of acpi_power_driver into acpi_scan_init() so that power resource devices can be initialized by it as soon as they have been found in the namespace. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Add function for updating device power state consistentlyRafael J. Wysocki2011-01-121-29/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add function acpi_bus_update_power() for reading the actual power state of an ACPI device and updating its device->power.state field in such a way that its power resources' reference counters will remain consistent with that field. For this purpose introduce __acpi_bus_set_power() setting the power state of an ACPI device without updating its device->power.state field and make acpi_bus_set_power() and acpi_bus_update_power() use it (acpi_bus_set_power() retains the current behavior for now). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | ACPI / PM: Add function for device power state initializationRafael J. Wysocki2011-01-123-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add function acpi_bus_init_power() for getting the initial power state of an ACPI device and reference counting its power resources as appropriate. Make acpi_bus_get_power_flags() use the new function instead of acpi_bus_get_power() that updates device->power.state without reference counting the device's power resources. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2025-01-28 22:36:34 +0000