aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'misc' into testLen Brown2008-10-2230-46/+56
|\
| * asus-laptop: Fix the led behavior with value > 1Corentin Chary2008-10-221-1/+1
| | | | | | | | | | | | | | Fix http://bugzilla.kernel.org/show_bug.cgi?id=11613 . Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI suspend: Fix CONFIG_ACPI_SLEEP dependence and some compilation warningsRafael J. Wysocki2008-10-222-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initially CONFIG_PM_SLEEP was defined as CONFIG_SUSPEND || CONFIG_HIBERNATION and some ACPI code, most importantly the code in drivers/acpi/main.c, was written with this assumption. Currently, however, CONFIG_PM_SLEEP is also set when CONFIG_XEN_SAVE_RESTORE is set. This causes some compilation warnings to appear in drivers/acpi/main.c if both CONFIG_SUSPEND and CONFIG_HIBERNATION are unset and CONFIG_PM_SLEEP is set (this was impossible before). To fix this problem, redefine CONFIG_ACPI_SLEEP do depend directly on CONFIG_SUSPEND || CONFIG_HIBERNATION, as originally intended, and use it instead of CONFIG_PM_SLEEP in drivers/acpi/main.c, wherever appropriate. Additionally, move the acpi_target_sleep_state definition from under the #ifdef to prevent compilation from failing in some cases. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * asus-laptop: Add support for P30/P35Torsten Krah2008-10-171-0/+1
| | | | | | | | | | | | | | | | | | Add support for P30/P35. http://bugzilla.kernel.org/show_bug.cgi?id=10848 Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: Allow overriding to higher critical trip point.Zhang Rui2008-10-172-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=9129 lenb: Note that overriding a critical trip point may simply fool the user into thinking that they have control that they do not actually have. For it is EC firmware that decides when the EC sends Linux temperature change events, and the EC may or may not decide to send Linux these events anywhere in the neighborhood of the fake override trip points. Beware. note also that thermal.nocrt is already available to disable crtical trip point actios, and thermal.crt=-1 is already available to disabled critical trip points entirely. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * don't load asus-acpi if model is not supportedZhang Rui2008-10-171-0/+2
| | | | | | | | | | | | | | | | asus_hotk_get_info should return -ENODEV if the model is not supported. http://bugzilla.kernel.org/show_bug.cgi?id=10389 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * sony-laptop: newline-terminate the printk for backlight change failureAdam Jackson2008-10-161-1/+1
| | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * fix CONFIG_MMCONFIG=n build warningPavel Vasilyev2008-10-151-1/+3
| | | | | | | | | | | | | | | | | | | | arch/x86/kernel/acpi/boot.c:100: warning: 'acpi_mcfg_64bit_base_addr' defined but not used http://bugzilla.kernel.org/show_bug.cgi?id=11743 Signed-off-by: Pavel Vasilyev <linuxoid@tochka.ru> Signed-off-by: Len Brown <len.brown@intel.com>
| * toshiba_acpi: depends on INPUTRandy Dunlap2008-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ACPI: catch calls of acpi_driver_data on pointer of wrong typePavel Machek2008-10-1023-30/+34
| | | | | | | | | | | | | | | | | | | | | | 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>
| * ACPI: toshiba_acpi.c fix sparse signedness mismatch warningsHarvey Harrison2008-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ACPI: acpi_driver_data could only be applied to acpi_deviceAlexey Starikovskiy2008-10-101-1/+1
| | | | | | | | | | | | | | | | Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Hannes Reinecke <hare@suse.de> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| * x86: trim ACPI sleep stack bufferMatt Mackall2008-10-101-1/+1
| | | | | | | | | | | | | | | | x86_64 SMP suspend to RAM uses a 10k temporary stack for saving the kernel state, but only 4k of it is used. Shrink it to 4k. Signed-off-by: Matt Mackall <mpm@selenic.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * x86: remove magic number from ACPI sleep stack bufferMatt Mackall2008-10-101-1/+1
| | | | | | | | | | | | | | | | | | x86_64 SMP suspend to RAM uses a 10k temporary stack for saving the kernel state, but only 4k of it is used. Shrink it to 4k. Signed-off-by: Matt Mackall <mpm@selenic.com> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'i7300_idle' into testLen Brown2008-10-2210-0/+713
|\ \
| * | i7300_idle driver v1.55Andy Henroid2008-10-219-0/+706
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Intel 7300 Memory Controller supports dynamic throttling of memory which can be used to save power when system is idle. This driver does the memory throttling when all CPUs are idle on such a system. Refer to "Intel 7300 Memory Controller Hub (MCH)" datasheet for the config space description. Signed-off-by: Andy Henroid <andrew.d.henroid@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
| * | x86 allow modules to register idle notifiersVenkatesh Pallipadi2008-10-211-0/+7
| |/ | | | | | | | | | | | | | | needed if the i7300_idle driver is to be modular. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'fujitsu' into testLen Brown2008-10-221-52/+71
|\ \
| * | fujitsu-laptop: better handling of P8010 hotkeyJonathan Woithe2008-10-101-52/+71
| |/ | | | | | | | | | | | | | | | | | | | | | | | | This patch (mostly from Peter Gruber) improves the handling of the hotkeys for P8010 laptops by passing more accurate input events back to userspace. This is needed because the P8010 labels these buttons quite differently to earlier laptops. As part of this, a P8010-specific DMI callback check has been implemented. Finally there's some minor whitespace cleanups from running the source through Lindent. Signed-off-by: Peter Gruber <nokos@gmx.net> Signed-off-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'fadt-test' into testLen Brown2008-10-221-7/+25
|\ \
| * | ACPI: fix FADT parsingJan Beulich2008-10-101-7/+25
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'eeepc' into testLen Brown2008-10-221-19/+209
|\ \
| * | eeepc-laptop: Use standard interfacesMatthew Garrett2008-10-101-19/+209
| |/ | | | | | | | | | | | | | | | | eeepc-laptop currently only sends key events via ACPI and has non-standard rfkill control. Add an input device and use the rfkill infrastructure. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'ec' into testLen Brown2008-10-224-187/+198
|\ \
| * | ACPI: EC: Check for IBF=0 periodically if not in GPE modeAlexey Starikovskiy2008-10-161-2/+13
| | | | | | | | | | | | | | | | | | 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>
| * | ACPI: Enable EC device immediately after ACPI full initializationZhao Yakui2008-10-113-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=11255 http://bugzilla.kernel.org/show_bug.cgi?id=11374 http://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>
| * | ACPI: EC: Rename some variablesAlexey Starikovskiy2008-09-291-55/+63
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI: EC: do transaction from interrupt contextAlexey Starikovskiy2008-09-251-160/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is easier and faster to do transaction directly from interrupt context rather than waking control thread. Also, cleaner GPE storm avoidance is implemented. References: http://bugzilla.kernel.org/show_bug.cgi?id=9998 http://bugzilla.kernel.org/show_bug.cgi?id=10724 http://bugzilla.kernel.org/show_bug.cgi?id=10919 http://bugzilla.kernel.org/show_bug.cgi?id=11309 http://bugzilla.kernel.org/show_bug.cgi?id=11549 Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'dock' into testLen Brown2008-10-2212-604/+422
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/osl.c Signed-off-by: Len Brown <len.brown@intel.com>
| * | | Subject: ACPI dock: Use ACPI_EXCEPTION instead of printk(KERN_ERRThomas Renninger2008-10-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | dock: Shaohua Li is new maintainerLen Brown2008-09-241-2/+2
| | | | | | | | | | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
| * | | dock: add 'type' sysfs fileShaohua Li2008-09-231-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | dock: fix for ATA bay in a dock stationShaohua Li2008-09-231-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | bay: remove driver, all functions now handled by dock driverShaohua Li2008-09-233-421/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | dock: introduce .uevent for devices in dock, eg libataShaohua Li2008-09-234-13/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | libata: remove functions now handed by ACPI dock driverShaohua Li2008-09-232-94/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI: fix hotplug raceZhang Rui2008-09-233-6/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI: introduce notifier change to avoid duplicatesShaohua Li2008-09-233-22/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | dock: add bay and battery hotplug supportShaohua Li2008-09-231-48/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | dock: add _LCK supportShaohua Li2008-09-231-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | dock: fix eject request process (2.6.27-rc1 regression)Shaohua Li2008-09-231-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | ACPI: dock: avoid check _STA methodShaohua Li2008-09-231-1/+4
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'cpuidle' into testLen Brown2008-10-223-1/+12
|\ \ \
| * | | cpuidle: upon BIOS bug, default to default_idle rather than pollingVenkatesh Pallipadi2008-10-162-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=11345 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | cpuidle: update the last_state acpi cpuidle reflecting actual state enteredVenkatesh Pallipadi2008-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | cpuidle: use last_state which can reflect the actual state enteredVenkatesh Pallipadi2008-10-161-1/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpuidle accounts the idle time for the C-state it was trying to enter and not to the actual state that the driver eventually entered. The driver may select a different state than the one chosen by cpuidle due to constraints like bus-mastering, etc. Change the time acounting code to look at the dev->last_state after returning from target_state->enter(). Driver can modify dev->last_state internally, inside the enter routine to reflect the actual C-state entered. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'bugzilla-11481' into testLen Brown2008-10-221-3/+22
|\ \ \
| * | | ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanismZhao Yakui2008-10-181-3/+22
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates whether the ACPI reboot mechanism is supported. However, some boxes have this bit clear, have a valid ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only mechanism that works for them after S3. This suggests that other operating systems may not be checking the RESET_REG_SUP bit, and are using other means to decide whether to use the ACPI reboot mechanism or not. Here we stop checking RESET_REG_SUP. Instead, When acpi reboot is requested, only the reset_register is checked. If the following conditions are met, it indicates that the reset register is supported. a. reset_register is not zero b. the access width is eight c. the bit_offset is zero http://bugzilla.kernel.org/show_bug.cgi?id=7299 http://bugzilla.kernel.org/show_bug.cgi?id=1148 Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'bugzilla-10503' into testLen Brown2008-10-221-0/+10
|\ \ \
| * | | ACPI: don't enable control method power button as wakeup device when Fixed ↵Zhang Rui2008-10-061-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Power button is used 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>
generated by cgit v1.1 at 2024-09-08 10:05:18 +0000