aboutsummaryrefslogtreecommitdiff
path: root/drivers/acpi
AgeCommit message (Collapse)Author
2008-12-15ACPI toshiba: only register rfkill if bt is enabledFrederik Deweerdt
Part of the rfkill initialization was done whenever BT was on or not. The following patch checks for BT presence before registering the rfkill to the input layer. Some minor cleanups (> 80 char lines) were also added in the process. On Tue, Oct 28, 2008 at 10:10:37PM +0300, Andrey Borzenkov wrote: [...] > [ 66.633036] toshiba_acpi: Toshiba Laptop ACPI Extras version 0.19 > [ 66.633054] toshiba_acpi: HCI method: \_SB_.VALD.GHCI > [ 66.637764] input: Toshiba RFKill Switch as /devices/virtual/input/input3 [...] > [ 113.920753] ------------[ cut here ]------------ > [ 113.920828] kernel BUG at /home/bor/src/linux-git/net/rfkill/rfkill.c:347! > [ 113.920845] invalid opcode: 0000 [#1] > [ 113.920877] last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/host0/target0:0:0/0:0:0:0/block/sda/size > [ 113.920900] Dumping ftrace buffer: > [ 113.920919] (ftrace buffer empty) > [ 113.920933] Modules linked in: af_packet irnet ppp_generic slhc ircomm_tty ircomm binfmt_misc loop dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath dm_mod alim15x3 ide_core nvram toshiba cryptomgr aead crypto_blkcipher michael_mic crypto_algapi orinoco_cs orinoco hermes_dld hermes pcmcia firmware_class snd_ali5451 snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device smsc_ircc2 snd_pcm_oss snd_pcm rtc_cmos irda snd_timer snd_mixer_oss rtc_core snd crc_ccitt yenta_socket rtc_lib rsrc_nonstatic i2c_ali1535 pcmcia_core pcspkr psmouse soundcore i2c_core evdev sr_mod snd_page_alloc alim1535_wdt cdrom fan sg video output toshiba_acpi rfkill thermal backlight ali_agp processor ac button input_polldev battery agpgart ohci_hcd usbcore reiserfs pata_ali libata sd_mod scsi_mod [last unloaded: scsi_wait_scan] > [ 113.921765] > [ 113.921785] Pid: 3272, comm: ipolldevd Not tainted (2.6.28-rc2-1avb #3) PORTEGE 4000 > [ 113.921801] EIP: 0060:[<dfaa4683>] EFLAGS: 00010246 CPU: 0 > [ 113.921854] EIP is at rfkill_force_state+0x53/0x90 [rfkill] > [ 113.921870] EAX: 00000000 EBX: 00000000 ECX: 00000003 EDX: 00000000 > [ 113.921885] ESI: 00000000 EDI: ddd50300 EBP: d8d7af40 ESP: d8d7af24 > [ 113.921900] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 > [ 113.921918] Process ipolldevd (pid: 3272, ti=d8d7a000 task=d8d93c90 task.ti=d8d7a000) > [ 113.921933] Stack: > [ 113.921945] d8d7af38 00000246 dfb029d8 dfb029c0 dfb029d8 dfb029c0 ddd50300 d8d7af5c > [ 113.922014] dfb018e2 01000246 01000000 ddd50300 ddd50314 ddabb8a0 d8d7af68 dfb381c1 > [ 113.922098] 00000000 d8d7afa4 c012ec0a 00000000 00000002 00000000 c012eba8 ddabb8c0 > [ 113.922240] Call Trace: > [ 113.922240] [<dfb018e2>] ? bt_poll_rfkill+0x5c/0x82 [toshiba_acpi] > [ 113.922240] [<dfb381c1>] ? input_polled_device_work+0x11/0x40 [input_polldev] > [ 113.922240] [<c012ec0a>] ? run_workqueue+0xea/0x1f0 > [ 113.922240] [<c012eba8>] ? run_workqueue+0x88/0x1f0 > [ 113.922240] [<dfb381b0>] ? input_polled_device_work+0x0/0x40 [input_polldev] > [ 113.922240] [<c012f047>] ? worker_thread+0x87/0xf0 > [ 113.922240] [<c0132b00>] ? autoremove_wake_function+0x0/0x50 > [ 113.922240] [<c012efc0>] ? worker_thread+0x0/0xf0 > [ 113.922240] [<c013280f>] ? kthread+0x3f/0x80 > [ 113.922240] [<c01327d0>] ? kthread+0x0/0x80 > [ 113.922240] [<c01040d7>] ? kernel_thread_helper+0x7/0x10 > [ 113.922240] Code: 43 54 89 73 54 39 c6 74 11 89 d9 ba 01 00 00 00 b8 40 68 aa df e8 3e 35 69 e0 89 f8 e8 77 fd 85 e0 31 c0 83 c4 10 5b 5e 5f 5d c3 <0f> 0b eb fe 89 f6 8d bc 27 00 00 00 00 be f4 4d aa df bb 5f 01 > [ 113.922240] EIP: [<dfaa4683>] rfkill_force_state+0x53/0x90 [rfkill] SS:ESP 0068:d8d7af24 > [ 113.924700] ---[ end trace 0e404eb40cadd5f0 ]--- Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com> Tested-by: Andrey Borzenkov <arvidjaar@mail.ru> Acked-by: Len Brown <len.brown@intel.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Philip Langdale <philipl@overt.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-12-05Revert "ACPI: battery: Convert discharge energy rate to current properly"Linus Torvalds
This reverts commit 558073dd56707864f09d563b64e7c37c021e89d2, along with the failed try to fix the regression it caused ("ACPI: Fix ACPI battery regression introduced by commit 558073"), which just made things worse. Commit aaad077638be1a25871bcae5e43952d6b63abfca (that failed "Fix ACPI battery regression") got the voltage conversion confused, and fixed the problem with Rafael's battery monitor apparently just by mistake. So revert them both, getting us back to the 2.6.27 state in this, and let's revisit it when people understand what's going on. Noted-by: Paul Martin <pm@debian.org> Requested-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <len.brown@intel.com> Cc: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-12-04ACPI: Fix ACPI battery regression introduced by commit 558073Rafael J. Wysocki
Commit 558073dd56707864f09d563b64e7c37c021e89d2 ("ACPI: battery: Convert discharge energy rate to current properly") caused the battery subsystem to report wrong values of the remaining time on battery power and the time until fully charged on Toshiba Portege R500 (and presumably on other boxes too). Fix the issue by correcting the conversion from mW to mA. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-28toshiba_acpi: close race in toshiba_acpi driverArjan van de Ven
the toshiba ACPI driver will, in a failure case, free the rfkill state before stopping the polling timer that would use this state. More interesting, in the same failure case handling, it calls the exit function, which also frees the rfkill state, but after stopping the polling. If the race happens, a NULL pointer is passed to rfkill_force_state() which then causes a nice dereference. Fix the race by just not doing the too-early freeing of the rfkill state. This appears to be the cause of a hot issue on kerneloops.org; while I have no solid evidence of that this patch will fix the issue, the race appears rather real. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-27ACPI: delete OSI(Linux) DMI dmesg spamLen Brown
Linux will continue to ignore OSI(Linux), except for a white-list containing a few systems. So delete the black-list, and stop soliciting user-feedback on the console. Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-26Revert "ACPI: don't enable control method power button as wakeup device when ↵Len Brown
Fixed Power button is used" This reverts commit faee816b1502385dc9bc5abf2960d1cc645844d1. http://bugzilla.kernel.org/show_bug.cgi?id=12091 Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-26ACPI suspend: Blacklist boxes that require us to set SCI_EN directly on resumeRafael J. Wysocki
Some Apple boxes evidently require us to set SCI_EN on resume directly, because if we don't do that, they hung somewhere in the resume code path. Moreover, on these boxes it is not sufficient to use acpi_enable() to turn ACPI on during resume. All of this is against the ACPI specification which states that (1) the BIOS is supposed to return from the S3 sleep state with ACPI enabled (SCI_EN set) and (2) the SCI_EN bit is owned by the hardware and we are not supposed to change it. For this reason, blacklist the affected systems so that the SCI_EN bit is set during resume on them. [NOTE: Unconditional setting SCI_EN for all system on resume doesn't work, because it makes some other systems crash (that's to be expected). Also, it is not entirely clear right now if all of the Apple boxes require this workaround.] This patch fixes the recent regression tracked as http://bugzilla.kernel.org/show_bug.cgi?id=12038 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Tino Keitel <tino.keitel@gmx.de> Tested-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-26ACPI: scheduling in atomic via acpi_evaluate_integer ()Pavel Machek
Now I know why I had strange "scheduling in atomic" problems: acpi_evaluate_integer() does malloc(..., irqs_disabled() ? GFP_ATOMIC : GFP_KERNEL)... which is (of course) broken. There's no way to reliably tell if we need GFP_ATOMIC or not from code, this one for example fails to detect spinlocks held. Fortunately, allocation seems small enough to be done on stack. Signed-off-by: Pavel Machek <pavel@suse.cz> Acked-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-26ACPI: battery: Convert discharge energy rate to current properlyAlexey Starikovskiy
ACPI battery interface reports its state either in mW or in mA, and discharge rate in your case is reported in mW. power_supply interface does not have such a parameter, so current_now parameter is used for all cases. But in case of mW, reported discharge should be converted into mA. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Ferenc Wagner <wferi@niif.hu> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-26ACPI: EC: count interrupts only if called from interrupt handler.Alexey Starikovskiy
fix 2.6.28 EC interrupt storm regression Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-16acpi: fix oops in acpi_system_wakeup_device_seq_showLinus Torvalds
Commit 0794469da3f7b2093575cbdfc1108308dd3641ce: ("ACPI: struct device - replace bus_id with dev_name(), dev_set_name()") introduced a bug by testing 'dev_name(ldev)' instead of 'ldev->bus' for NULL when printing out the bus information. So if ldev->bus was NULL, we'd oops. Reported-and-tested-by: Bruno Prémont <bonbons@linux-vserver.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Len Brown <len.brown@intel.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-11-11Merge branch 'ec' into releaseLen Brown
2008-11-11Merge branch 'processor-256' into releaseLen Brown
2008-11-11Merge branch 'video' into releaseLen Brown
Conflicts: Documentation/kernel-parameters.txt Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11Merge branch 'sysfs' into releaseLen Brown
2008-11-11Merge branch 'power' into releaseLen Brown
2008-11-11Merge branch 'misc' into releaseLen Brown
2008-11-11Merge branch 'bugzilla-11917' into releaseLen Brown
2008-11-11Merge branch 'bugzilla-11539' into releaseLen Brown
2008-11-11ACPI: pci_link: remove acpi_irq_balance_set() interfaceBjorn Helgaas
This removes the acpi_irq_balance_set() interface from the PCI interrupt link driver. x86 used acpi_irq_balance_set() to tell the PCI interrupt link driver to configure links to minimize IRQ sharing. But the link driver can easily figure out whether to turn on IRQ balancing based on the IRQ model (PIC/IOAPIC/etc), so we can get rid of that external interface. It's better for the driver to figure this out at init-time. If we set it externally via the x86 code, the interface reduces modularity, and we depend on the fact that acpi_process_madt() happens before we process the kernel command line. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPI: EC: Don't do transaction from GPE handler in poll mode.Alexey Starikovskiy
Referencies: http://bugzilla.kernel.org/show_bug.cgi?id=12004 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPI: EC: lower interrupt storm tresholdAlexey Starikovskiy
http://bugzilla.kernel.org/show_bug.cgi?id=11892 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPICA: Use spinlock for acpi_{en|dis}able_gpeAlexey Starikovskiy
Disabling gpe might interfere with gpe detection/handling, thus producing "interrupt not handled" errors. Ironically, disabling of GPE from interrupt context is already under spinlock, so only userspace needs to start using it. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPI: EC: restart failed commandAlexey Starikovskiy
Restart current transaction if we recieved unexpected GPEs instead of needed ones. http://bugzilla.kernel.org/show_bug.cgi?id=11896 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPI: EC: wait for last write gpeAlexey Starikovskiy
There is a possibility that EC might break if next command is issued within 1 us after write or burst-disable command. Suggestd-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPI: EC: make kernel messages more useful when GPE storm is detectedAlan Jenkins
Make sure we can tell if the GPE storm workaround gets activated, and avoid flooding the logs afterwards. http://bugzilla.kernel.org/show_bug.cgi?id=11841 "plenty of line "ACPI: EC: non-query interrupt received, switching to interrupt mode" in dmesg" Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-11ACPI: EC: revert msleep patchAlexey Starikovskiy
With the better solution for EC interrupt storm issue, there is no need to use msleep over udelay. References: http://bugzilla.kernel.org/show_bug.cgi?id=11810 http://bugzilla.kernel.org/show_bug.cgi?id=10724 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI video: if no ACPI backlight support, use vendor driversThomas Renninger
If an ACPI graphics device supports backlight brightness functions (cmp. with latest ACPI spec Appendix B), let the ACPI video driver control backlight and switch backlight control off in vendor specific ACPI drivers (asus_acpi, thinkpad_acpi, eeepc, fujitsu_laptop, msi_laptop, sony_laptop, acer-wmi). Currently it is possible to load above drivers and let both poke on the brightness HW registers, the video and vendor specific ACPI drivers -> bad. This patch provides the basic support to check for BIOS capabilities before driver loading time. Driver specific modifications are in separate follow up patches. "acpi_backlight=vendor" Prever vendor driver over ACPI driver for backlight. "acpi_backlight=video" (default) Prever ACPI driver over vendor driver for backlight. Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI: video: Ignore devices that aren't present in hardwareThomas Renninger
This is a reimplemention of commit 0119509c4fbc9adcef1472817fda295334612976 from Matthew Garrett <mjg59@srcf.ucam.org> This patch got removed because of a regression: ThinkPads with a Intel graphics card and an Integrated Graphics Device BIOS implementation stopped working. In fact, they only worked because the ACPI device of the discrete, the wrong one, got used (via int10). So ACPI functions were poking on the wrong hardware used which is a sever bug. The next patch provides support for above ThinkPads to be able to switch brightness via the legacy thinkpad_acpi driver and automatically detect when to use it. Original commit message from Matthew Garrett: Vendors often ship machines with a choice of integrated or discrete graphics, and use the same DSDT for both. As a result, the ACPI video module will locate devices that may not exist on this specific platform. Attempt to determine whether the device exists or not, and abort the device creation if it doesn't. http://bugzilla.kernel.org/show_bug.cgi?id=9614 Signed-off-by: Thomas Renninger <trenn@suse.de> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07Delete an unwanted return statement at evgpe.cLin Ming
Len's tree branch release-2.6.27, found an unwanted return statement at evgpe.c. (git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 release-2.6.27) Signed-of-by Lin Ming <ming.m.lin@intel.com> Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI: update debug parameter documentationBjorn Helgaas
Reformat acpi.debug_layer and acpi.debug_level documentation so it's more readable, add some clues about how to figure out the mask bits that enable a specific ACPI_DEBUG_PRINT statement, and include some useful examples. Move the list of masks to Documentation/acpi/debug.txt (these are copies of the authoritative values in acoutput.h and acpi_drivers.h). Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI: turn off all debug output by defaultBjorn Helgaas
When CONFIG_ACPI_DEBUG=y, the default acpi_dbg_layer and acpi_dbg_level values built into the ACPI CA have some debug output enabled. We'd rather be quiet unless the user actually specified the acpi.debug_level argument. This enables distros to ship with CONFIG_ACPI_DEBUG=y without inundating users with debug output. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI: add driver component definitions to sysfs debug_layersBjorn Helgaas
/sys/module/acpi/parameters/debug_layers used to contain only the debug layers defined by the ACPI CA. This patch adds the additional layer definitions for ACPI drivers. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI: consolidate ACPI_*_COMPONENT definitions in acpi_drivers.hBjorn Helgaas
Move all the component definitions for drivers to a single shared place, include/acpi/acpi_drivers.h. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-07ACPI EC: Fix regression due to use of uninitialized variableAlexey Starikovskiy
breakage introduced by following patch commit 27663c5855b10af9ec67bc7dfba001426ba21222 Author: Matthew Wilcox <willy@linux.intel.com> Date: Fri Oct 10 02:22:59 2008 -0400 acpi_evaluate_integer() does not clear passed variable if there is an error at evaluation. So if we ignore error, we must supply initialized variable. http://bugzilla.kernel.org/show_bug.cgi?id=11917 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>
2008-11-06ACPI: avoid empty file name in sysfsPeter Gruber
Since commit bc45b1d39a925b56796bebf8a397a0491489d85c acpi tables are allowed to have an empty signature and /sys/firmware/acpi/tables uses the signature as filename. Applications using naive recursion through /sys loop forever. A possible solution would be: (replacing the zero length filename with the string "NULL") http://bugzilla.kernel.org/show_bug.cgi?id=11539 Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: use macro to replace hard numberYinghai Lu
Impact: cleanup Use MACRO for rev 3 fadt id instead of 3 directly. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers
This patch is part of a larger patch series which will remove the "char bus_id[20]" name string from struct device. The device name is managed in the kobject anyway, and without any size limitation, and just needlessly copied into "struct device". To set and read the device name dev_name(dev) and dev_set_name(dev) must be used. If your code uses static kobjects, which it shouldn't do, "const char *init_name" can be used to statically provide the name the registered device should have. At registration time, the init_name field is cleared, to enforce the use of dev_name(dev) to access the device name at a later time. We need to get rid of all occurrences of bus_id in the entire tree to be able to enable the new interface. Please apply this patch, and possibly convert any remaining remaining occurrences of bus_id. We want to submit a patch to -next, which will remove bus_id from "struct device", to find the remaining pieces to convert, and finally switch over to the new api, which will remove the 20 bytes array and does no longer have a size limitation. Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-Off-By: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06Revert "ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism"Len Brown
This reverts commit 8fd145917fb62368a9b80db59562c20576238f5a. http://bugzilla.kernel.org/show_bug.cgi?id=11942 Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: 80 column adherence and spelling fix (no functional change)Myron Stowe
Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: Behave uniquely based on processor declaration definition typeMyron Stowe
Associating a Local SAPIC with a processor object is dependent upon the processor object's definition type. CPUs declared as "Processor" should use the Local SAPIC's 'processor_id', and CPUs declared as "Device" should use the 'uid'. Note that for "Processor" declarations, even if a '_UID' child object exists, it has no bearing with respect to mapping Local SAPICs (see section 5.2.11.13 - Local SAPIC Structure; "Advanced Configuration and Power Interface Specification", Revision 3.0b). This patch changes the lsapic mapping logic to rely on the distinction of how the processor object was declared - the mapping can't just try both types of matches regardless of declaration type and rely on one failing as is currently being done. Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: Disambiguate processor declaration typeMyron Stowe
Declaring processors in ACPI namespace can be done using either a "Processor" definition or a "Device" definition (see section 8.4 - Declaring Processors; "Advanced Configuration and Power Interface Specification", Revision 3.0b). Currently the two processor declaration types are conflated. This patch disambiguates the processor declaration's definition type enabling subsequent code to behave uniquely based explicitly on the declaration's type. Signed-off-by: Myron Stowe <myron.stowe@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: remove CONFIG_ACPI_ECBjorn Helgaas
Remove CONFIG_ACPI_EC. It was always set the same as CONFIG_ACPI, and it had no menu label, so there was no way to set it to anything other than "y". Per section 6.5.4 of the ACPI 3.0b specification, OSPM must make Embedded Controller operation regions, accessed via the Embedded Controllers described in ECDT, available before executing any control method. The ECDT table is optional, but if it is present, the above text means that the EC it describes is a required part of the ACPI subsystem, so CONFIG_ACPI_EC=n wouldn't make sense. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: remove CONFIG_ACPI_POWERBjorn Helgaas
Remove CONFIG_ACPI_POWER. It was always set the same as CONFIG_ACPI, and it had no menu label, so there was no way to set it to anything other than "y". The interfaces under CONFIG_ACPI_POWER (acpi_device_sleep_wake(), acpi_power_transition(), etc) are called unconditionally from the ACPI core, so we already depend on it always being present. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: SBS: remove useless acpi_cm_sbs_init() initcallBjorn Helgaas
acpi_cm_sbs_init() doesn't do anything, so we can just remove it. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-11-06ACPI: remove comments about debug layer/level to useBjorn Helgaas
I don't think there's any point in cluttering the code with these. Better to improve the documentation so *anybody* can figure out what layer & level to use. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-28ACPI: bugfix reporting of event handler statusZhang Rui
Introduce a new flag showing whether the event has an event handler/method. For all the GPEs and Fixed Events, 1. ACPI_EVENT_FLAG_HANDLE is cleared, it's an "invalid" ACPI event. 2. Both ACPI_EVENT_FLAG_HANDLE and ACPI_EVENT_FLAG_DISABLE are set, it's "disabled". 3. Both ACPI_EVENT_FLAG_HANDLE and ACPI_EVENT_FLAG_ENABLE are set, it's "enabled". 4. Both ACPI_EVENT_FLAG_HANDLE and ACPI_EVENT_FLAG_WAKE_ENABLE are set, it's "wake_enabled". Among other things, this prevents incorrect reporting of ACPI events as being "invalid" when it's really just (temporarily) "disabled". Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-28ACPI: fan: Delete the strict check in power transitionZhao Yakui
On some laptops the Fan device is turned on/off by controlling the corresponding power resource. For example: If the power resource defined in _PR0 object is turned off, it indicates that the FAN device is in off state(the ACPI state is in D3 state). Maybe the device is already in D3 state and expected to be transited to D3 state. As there is no _PR3 object, the power transition can't be finished and it will be switched to the Unknown state. Maybe it is more reasonable that the strick check in power transistion is deleted. http://bugzilla.kernel.org/show_bug.cgi?id=9485 Signed-off-by: yakui.zhao@intel.com Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-28ACPI: fix de-reference bug in power resource driverZhao Yakui
change state to *state in the function of acpi_power_get_state() Signed-off-by: yakui.zhao@intel.com Signed-off-by: Len Brown <len.brown@intel.com>
2008-10-25ACPI suspend: build fix for ACPI_SLEEP=n && XEN_SAVE_RESTORE=y.Rafael J. Wysocki
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>