According to the ACPI specification 2.0c and later, the 64-bit waking vector
should be cleared and the 32-bit waking vector should be used, unless we want
the wake-up code to be called by the BIOS in Protected Mode. Moreover, some
systems (for example HP dv5-1004nr) are known to fail to resume if the 64-bit
waking vector is used. Therefore, modify the code to clear the 64-bit waking
vector, for FACS version 1 or greater, and set the 32-bit one before suspend.
http://bugzilla.kernel.org/show_bug.cgi?id=11368
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
The _TTS object is defined in the section 7.3 of acpi 3.0b spec.
The _TTS control method is executed by the OSPM at the beginning of
the sleep transition process for S1,S2, S3, S4, and orderly S5 shutdown.
OS will invoke _TTS before it has notified any native mode device drivers
of the sleep state transition. The target sleeping state value is passed to
the _TTS control method.
The _TTS control method is also executed by the OSPM at the end of
any sleep transition process when the system transitions to S0 from
S1, S2, S3, or S4. The _TTS object should be evaluated after it has
notified any native mode device drivers of the end of the sleep state
transition. The working state value (0) is passed to the _TTS control method.
So it is necessary to add the support for _TTS object. The _TTS object
will be evaluated if it exists.
At the same time a block notifier is added to the reboot notifier list so
that the _TTS object will also be evaluated when the system shutdown.
lenb: note that as of Sep 2008, I've not yet seen _TTS in any shipping BIOS.
So this patch is to future-proof Linux, rather than fix the installed base.
http://bugzilla.kernel.org/show_bug.cgi?id=11132
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Li Shaohua <shaohua.li@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
reflect the actual state entered in dev->last_state, when actaul state entered
is different from intended one.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The leading other brand OS appears to clear the WAK_STS flag on resume.
When rebooted, certain BIOSes assume that the system is actually
resuming if it's still set and so fail to reboot correctly. Make sure
that it's cleared at resume time.
Comment clarified as suggested by Bob Moore
http://bugzilla.kernel.org/show_bug.cgi?id=11634
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Move rtc_wake_setup() from drivers/acpi/glue.c into the RTC driver
in drivers/rtc/rtc-cmos.c.
This removes the ordering constraint between the module_init(acpi_rtc_init)
and the cmos_do_probe() code that depends on it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit ed458df4d2470adc02762a87a9ad665d0b1a2bd4 ("PnP: move
pnpacpi/pnpbios_init to after PCI init") moved the PnP RTC discovery
later, and now the ACPI RTC glue code doesn't find it any more, breaking
the RTC wakealarm sysfs interfaces, as reported by Rafael.
This really is fairly messy, and we have several annoying ordering
constraints here - the PnP code that sets up the RTC resources wants to
run after the PCI resources have to be registered, which in turn needs
to run after ACPI has at least enumerated the root PCI buses etc. Our
initcall ordering is not fine-grained enough to make this all painless.
So this moves the ACPI RTC glue ("acpi_rtc_init()") down to a regular
module call, which fixes the problem Rafael has. The reason this isn't
wonderful is that we really should do acpi_rtc_init before we do the
rtc_cmos init, and now those two are in the same module_init() section.
Which happens to work, but only because drivers/rtc is linked after
drivers/acpi. In other words, we still have a very subtle ordering
issue here. Grr.
Reported-and-tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: David Brownell <david-b@pacbell.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As of version 2.0, ACPI can return 64-bit integers. The current
acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
Change the argument to take a pointer to an acpi_integer so we support
64-bit integers on all platforms.
lenb: replaced use of "acpi_integer" with "unsigned long long"
lenb: fixed bug in acpi_thermal_trips_update()
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
when there is no ECDT table and no _INI object for EC device, it will be
enabled before scanning ACPI device. But it is too late after the following
the commit is merged.
>commit 7752d5cfe3d11ca0bb9c673ec38bd78ba6578f8e
> Author: Robert Hancock <hancockr@shaw.ca>
> Date: Fri Feb 15 01:27:20 2008 -0800
>x86: validate against acpi motherboard resources
After the above commit is merged, OS will check whether MCFG area is
reserved in ACPI motherboard resources by calling the function of
acpi_get_devices when there exists MCFG table. In the acpi_get_devices the _STA
object will be evaluated to check the status of the ACPI device. On some broken
BIOS the MYEC object of EC device is initialized as one, which indicates that
EC operation region is already accessible before enabling EC device.So on these
broken BIOS the EC operation region will be accessed in course of evaluating
the _STA object before enabling EC device, which causes that OS will print the
following warning messages:
>ACPI Error (evregion-0315): No handler for Region [EC__] (ffff88007f8145e8)
[EmbeddedControl] [20080609]
>ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321]
>ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.
EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST
>ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1.
_STA] (Node ffff81013fc17a00), AE_NOT_EXIST
Although the above warning message is harmless, it looks confusing.
So it is necessary to enable EC device as early as possible.Maybe it is
appropriate to enable it immediately after ACPI full initialization.
http://bugzilla.kernel.org/show_bug.cgi?id=11255http://bugzilla.kernel.org/show_bug.cgi?id=11374http://bugzilla.kernel.org/show_bug.cgi?id=11660
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
lenb: stripped patch down to what still applied to new dock.c
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
CONFIG_ACPI_TOSHIBA can =y when CONFIG_INPUT=m, so prevent that
combination and its subsequent build errors:
toshiba_acpi.c:(.text+0x3e877): undefined reference to `input_event'
toshiba_acpi.c:(.text+0x3e98a): undefined reference to `input_unregister_polled_device'
toshiba_acpi.c:(.text+0x3e994): undefined reference to `input_free_polled_device'
toshiba_acpi.c:(.init.text+0x21b4): undefined reference to `input_allocate_polled_device'
toshiba_acpi.c:(.init.text+0x2263): undefined reference to `input_register_polled_device'
make[1]: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Catch attempts to use of acpi_driver_data on pointers of wrong type.
akpm: rewritten to use proper C typechecking and remove the
"function"-used-as-lvalue thing.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
set_bit expects unsigned int, and we start with a u32 anyway.
drivers/acpi/toshiba_acpi.c:397:14: warning: incorrect type in argument 1 (different signedness)
drivers/acpi/toshiba_acpi.c:397:14: expected unsigned int [usertype] *word
drivers/acpi/toshiba_acpi.c:397:14: got int *<noident>
drivers/acpi/toshiba_acpi.c:399:14: warning: incorrect type in argument 1 (different signedness)
drivers/acpi/toshiba_acpi.c:399:14: expected unsigned int [usertype] *word
drivers/acpi/toshiba_acpi.c:399:14: got int *<noident>
drivers/acpi/toshiba_acpi.c:401:14: warning: incorrect type in argument 1 (different signedness)
drivers/acpi/toshiba_acpi.c:401:14: expected unsigned int [usertype] *word
drivers/acpi/toshiba_acpi.c:401:14: got int *<noident>
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The (1.0 inherited) separate length fields in the FADT are byte granular.
Further, PM1a/b may have distinct lengths (if using the v2 fields was
okay) and may live in distinct address spaces. acpi_tb_convert_fadt()
should account for all of these conditions.
Apart from these changes I'm puzzled by the fact that, not just for
acpi_gbl_xpm1{a,b}_enable, acpi_hw_low_level_{read,write}() get an
explicit size passed rather than using the size found in the passed GAS.
What happens on a platform that defines PM1{a,b} wider than 16 bits? Of
course, acpi_hw_low_level_{read,write}() at present are entirely
un-prepared to deal with sizes other than 8, 16, or 32, not to speak of a
non-zero bit_offset or access_width...
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
According to the ACPI-WMI spec, event blocks may provide a function call
for enabling/disabling them. This patch adds support for making these
calls when registering or removing notifications. Without this, my Dell
firmware provides no data in the event notification.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
don't enable control method power button as wakeup device
when Fixed Power button is used.
http://bugzilla.kernel.org/show_bug.cgi?id=10503
Tested-by: walken@zoy.org <walken@zoy.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Make the ACPI /proc/acpi/wakeup interface set the appropriate wake-up bits
of physical devices corresponding to the ACPI devices and make those bits
be set initially for devices that are enabled to wake up by default. This
is needed to restore the 2.6.26 and earlier behavior for the PCI devices
that were previously handled correctly with the help of the
/proc/acpi/wakeup interface.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
No functional changes.
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Rafael J. Wysocki <rjw@suse.com>
Signed-off-by: Len Brown <len.brown@intel.com>
add a sysfs file to present dock type. Suggested by Holger.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
an ATA bay can be in a dock and itself can be ejected separately.
This patch handles such eject bay. Found by Holger.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
dock's uevent reported itself, not ata. It might be difficult to find an
ata device just according to a dock. This patch introduces docking ops
for each device in a dock. when docking, dock driver can send device
specific uevent. This should help dock station too (not just bay)
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
dock driver can handle ata(bay) hotplug now. dock driver already handles
_EJ0 and _STA, so remove them. Also libata doesn't need register
notification handler anymore.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The hotplug notification handler and drivers' notification handler all
run in one workqueue. Before hotplug removes an acpi device, the
device driver's notification handler is already be recorded to run just
after global notification handler. After hotplug notification handler
runs, acpica will notice a NULL notification handler and crash.
So now we run run hotplug in another workqueue and wait
for all acpi notication handlers finish.
This was found in battery hotplug, but actually all
hotplug can be affected.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The battery driver already registers notification handler.
To avoid registering notification handler again,
introduce a notifier chain in global system notifier handler
and use it in dock driver.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Make the dock driver support bay and battery hotplug.
They are all regarded as dock, so handling can be unified.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
support _LCK method, which is a optional method for hotplug
lenb: we have not seen _LCK used in the field yet
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
commit 2a7feab28d3fc060d320eaba192e49dad1079b7e introduces a bug.
My thinkpad actually will send an eject_request and we should follow the
eject process to finish the eject, otherwise system still thinks the bay
is present.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
In some BIOSes, every _STA method call will send a notification again,
this cause freeze. And in some BIOSes, it appears _STA should be called
after _DCK. This tries to avoid calls _STA, and still keep the device
present check.
http://bugzilla.kernel.org/show_bug.cgi?id=10431
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
On Intel CPUs it is rather common and a good hint that BIOSes which do provide
_PPC func, but not the frequencies itself in _PSS function, are old and need
to be updated for CPU freq support.
Tell the user/vendor he has a BIOS/firmware problem.
Make use of FW_BUG interface to give vendors and users the ability to
automatically check with (or let linuxfirmwarekit do that):
dmesg |grep "Firmware Bug"
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
There's been a patch floating around for toshiba_acpi that exports an ad-hoc
/proc interface to toggle the bluetooth adapter in a large number of Toshiba
laptops. I'm not sure if it's still relevant for the latest models, but it is
still required for older models such as my Tecra M3.
This change pulls in the low level Toshiba-specific code from the old patch and
sets up an rfkill device and a polled input device to track the state of the
hardware kill-switch.
Signed-off-by: Philip Langdale <philipl@overt.org>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In the function of wait_transaction_complete when the timeout happens,
OS will try to check the status of SMbus again. If the status is what OS
expected, it will be regarded as the bogus timeout. Otherwise it will be
treated as ETIME.
http://bugzilla.kernel.org/show_bug.cgi?id=10483
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
tested-by : Oldřich Jedlička < <oldium.pro@seznam.cz>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
The early_param handling function could recieve NULL pointer as argument
in case if user didn't enter parameter value. So we have to be ready for
a such situation and do check for NULL pointer if needed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
This fixes a typo in commit 2a2a64714d9c40f7705c4de1e79a5b855c7211a9
"Disable MWAIT via DMI on broken Compal board".
It allows the nomwait dmi check to actually detect the Acer 5220.
Signed-off-by: Dennis Jansen <dennis.jansen@web.de>
Tested-by: Dennis Jansen <dennis.jansen@web.de>
Acked-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Do not use unsigned int if there is test for negative number...
See drivers/acpi/processor_perflib.c
static unsigned int ignore_ppc = -1;
...
if (event == CPUFREQ_START && ignore_ppc <= 0) {
ignore_ppc = 0;
...
Signed-off-by: Milan Broz <mbroz@redhat.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
acpi_penalize_isa_irq() should validate irq before using it to
index the acpi_irq_penalty[] table.
Here's the path I'm concerned about:
pnpacpi_parse_allocated_irqresource()
{
...
irq = acpi_register_gsi(gsi, triggering, polarity);
if (irq >= 0)
pcibios_penalize_isa_irq(irq, 1);
There's no guarantee that acpi_register_gsi() will return an IRQ
within the bounds of acpi_irq_penalty[].
I have not seen a failure I can attribute to this. However,
ACPI_MAX_IRQS is only 256, and I'm pretty sure ia64 can have
IRQs larger than that.
I think this should go in 2.6.27.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
When EC is in Polling mode, OS will check the EC status continually by using
the following source code:
clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
while (time_before(jiffies, delay)) {
if (acpi_ec_check_status(ec, event))
return 0;
msleep(1);
}
But msleep is realized by the function of schedule_timeout. At the same time
although one process is already waken up by some events, it won't be scheduled
immediately. So maybe there exists the following phenomena:
a. The current jiffies is already after the predefined jiffies.
But before timeout happens, OS has no chance to check the EC
status again.
b. If preemptible schedule is enabled, maybe preempt schedule will happen
before checking loop. When the process is resumed again, maybe
timeout already happens, which means that OS has no chance to check
the EC status.
In such case maybe EC status is already what OS expects when timeout happens.
But OS has no chance to check the EC status and regards it as AE_TIME.
So it will be more appropriate that OS will try to check the EC status again
when timeout happens. If the EC status is what we expect, it won't be regarded
as timeout. Only when the EC status is not what we expect, it will be regarded
as timeout, which means that EC controller can't give a response in time.
http://bugzilla.kernel.org/show_bug.cgi?id=9823http://bugzilla.kernel.org/show_bug.cgi?id=11141
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
On some ASUS laptops the ECDT gives the incorrect command/status & Data I/O
register address.
AK: it seems like the command/data addresses are exchanged.
In such case it will cause that EC device can't be
initialized correctly.
To add the EC dmi table is to fix this issue. If the laptop falls into the
EC dmi table, the EC command/data I/O address will be fixed.
AK: Add comments describing this better
http://bugzilla.kernel.org/show_bug.cgi?id=9399
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
tested-by : Jan Kasprzak <kas@fi.muni.cz>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
