- 21 9月, 2009 1 次提交
-
-
由 Felipe Contreras 提交于
Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Cc: Vegard Nossum <vegardno@ifi.uio.no> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alok N Kataria <akataria@vmware.com> Cc: "Tan Wei Chong" <wei.chong.tan@intel.com> Cc: Len Brown <len.brown@intel.com> Cc: Lin Ming <ming.m.lin@intel.com> Cc: Bob Moore <robert.moore@intel.com> LKML-Reference: <1253137123-18047-2-git-send-email-felipe.contreras@gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 10 9月, 2009 4 次提交
-
-
由 Rafael J. Wysocki 提交于
Some PCI devices (not PCI Express), like PCI add-on cards, can generate PME#, but they don't have any special platform wake-up support. For this reason, even if they generate PME# to wake up the system from a sleep state, wake-up events are not generated by the platform. It turns out that, at least on some systems, PCI bridges and the PCI host bridge have ACPI GPEs associated with them that, if enabled to generate wake-up events, allow the system to wake up if one of the add-on devices asserts PME# while the system is in a sleep state. Following this observation, if a PCI device without direct ACPI wake-up support is prepared to wake up the system during a transition into a sleep state (eg. suspend to RAM), try to configure the bridges on the path from the device to the root bridge to wake-up the system. Reviewed-by: NMatthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
The wakeup.prepared flag is used for marking devices that have the wake-up power already enabled, so that the wake-up power is not enabled twice in a row for the same device. This assumes, however, that device wake-up power will only be enabled once, while the device is being prepared for a system-wide sleep transition, and the second attempt is made by acpi_enable_wakeup_device_prep(). With the upcoming PCI wake-up rework this assumption will not hold any more for PCI bridges and the root bridge whose wake-up power may be enabled as a result of wake-up enable propagation from other devices (eg. add-on devices that are not associated with any GPEs). Thus, there may be many attempts to enable wake-up power on a PCI bridge or the root bridge during a system power state transition and it's better to replace wakeup.prepared with a reference counter. Reviewed-by: NMatthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Move a debug message from acpi_pci_sleep_wake() to acpi_pm_device_sleep_wake() and use the standard dev_*() macros in there. Reviewed-by: NMatthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Alex Chiang 提交于
We can simplify ACPI drivers if we can tell whether a handle is an ACPI PCI root or not. Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 09 9月, 2009 1 次提交
-
-
由 Tejun Heo 提交于
There are cases where full date information is required instead of just the year. Add month and day parsing to dmi_get_year() and rename it to dmi_get_date(). As the original function only required '/' followed by any number of parseable characters at the end of the string, keep that behavior to avoid upsetting existing users. The new function takes dates of format [mm[/dd]]/yy[yy]. Year, month and date are checked to be in the ranges of [1-9999], [1-12] and [1-31] respectively and any invalid or out-of-range component is returned as zero. The dummy implementation is updated accordingly but the return value is updated to indicate field not found which is consistent with how other dummy functions behave. Signed-off-by: NTejun Heo <tj@kernel.org> Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
-
- 02 9月, 2009 1 次提交
-
-
由 Shane Wang 提交于
Move tboot.h from asm to linux to fix the build errors of intel_txt patch on non-X86 platforms. Remove the tboot code from generic code init/main.c and kernel/cpu.c. Signed-off-by: NShane Wang <shane.wang@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 29 8月, 2009 2 次提交
-
-
由 Keith Packard 提交于
acpi_video_put_one_device was attempting to remove sysfs entries and unregister a backlight device without first checking that said backlight device structure had been created. Signed-off-by: NKeith Packard <keithp@keithp.com> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
Fix a compatibility issue when the same buffer or string is stored to itself. This has been seen in the field. Previously, ACPICA would zero out the buffer/string. Now, the operation is treated as a NOP. http://bugzilla.acpica.org/show_bug.cgi?id=803Reported-by: NRezwanul Kabir <Rezwanul_Kabir@Dell.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 27 8月, 2009 3 次提交
-
-
由 Frans Pop 提交于
This failure is very common on many platforms. Handling it in the ACPI processor driver is enough, and we don't need a warning message unless CONFIG_ACPI_DEBUG is set. Based on a patch from Zhang Rui. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389Signed-off-by: NFrans Pop <elendil@planet.nl> Acked-by: NZhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Frans Pop 提交于
If the BIOS reports an invalid throttling state (which seems to be fairly common after system boot), a reset is done to state T0. Because of a check in acpi_processor_get_throttling_ptc(), the reset never actually gets executed, which results in the error reoccurring on every access of for example /proc/acpi/processor/CPU0/throttling. Add a 'force' option to acpi_processor_set_throttling() to ensure the reset really takes effect. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389 This patch, together with the next one, fixes a regression introduced in 2.6.30, listed on the regression list. They have been available for 2.5 months now in bugzilla, but have not been picked up, despite various reminders and without any reason given. Google shows that numerous people are hitting this issue. The issue is in itself relatively minor, but the bug in the code is clear. The patches have been in all my kernels and today testing has shown that throttling works correctly with the patches applied when the system overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14). Signed-off-by: NFrans Pop <elendil@planet.nl> Acked-by: NZhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Yinghai Lu 提交于
Jens reported early_ioremap messages with old ASUS board... > [ 1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling > [ 1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36 > [ 1.561007] Call Trace: > [ 1.568638] [<c136e48b>] ? printk+0x18/0x1d > [ 1.581734] [<c15513ff>] __early_ioremap+0x74/0x1e9 > [ 1.596898] [<c15515aa>] early_ioremap+0x1a/0x1c > [ 1.611270] [<c154a187>] __acpi_map_table+0x18/0x1a > [ 1.626451] [<c135a7f8>] acpi_os_map_memory+0x1d/0x25 > [ 1.642129] [<c119459c>] acpi_tb_verify_table+0x20/0x49 > [ 1.658321] [<c1193e50>] acpi_get_table_with_size+0x53/0xa1 > [ 1.675553] [<c1193eae>] acpi_get_table+0x10/0x15 > [ 1.690192] [<c155cc19>] acpi_processor_init+0x23/0xab > [ 1.706126] [<c1001043>] do_one_initcall+0x33/0x180 > [ 1.721279] [<c155cbf6>] ? acpi_processor_init+0x0/0xab > [ 1.737479] [<c106893a>] ? register_irq_proc+0xaa/0xc0 > [ 1.753411] [<c10689b7>] ? init_irq_proc+0x67/0x80 > [ 1.768316] [<c15405e7>] kernel_init+0x120/0x176 > [ 1.782678] [<c15404c7>] ? kernel_init+0x0/0x176 > [ 1.797062] [<c10038b7>] kernel_thread_helper+0x7/0x10 > [ 1.812984] 00000080 + ffe00000 that is rather later. acpi_gbl_permanent_mmap should be set in acpi_early_init() if acpi is not disabled and we have > [ 0.000000] ASUS P2B-DS detected: force use of acpi=ht just don't load acpi_processor_init... Reported-and-tested-by: NJens Rosenboom <jens@leia.mcbone.net> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NIngo Molnar <mingo@elte.hu> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 8月, 2009 1 次提交
-
-
由 Suresh Siddha 提交于
Currently clockevents_notify() is called with interrupts enabled at some places and interrupts disabled at some other places. This results in a deadlock in this scenario. cpu A holds clockevents_lock in clockevents_notify() with irqs enabled cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled cpu C doing set_mtrr() which will try to rendezvous of all the cpus. This will result in C and A come to the rendezvous point and waiting for B. B is stuck forever waiting for the spinlock and thus not reaching the rendezvous point. Fix the clockevents code so that clockevents_lock is taken with interrupts disabled and thus avoid the above deadlock. Also call lapic_timer_propagate_broadcast() on the destination cpu so that we avoid calling smp_call_function() in the clockevents notifier chain. This issue left us wondering if we need to change the MTRR rendezvous logic to use stop machine logic (instead of smp_call_function) or add a check in spinlock debug code to see if there are other spinlocks which gets taken under both interrupts enabled/disabled conditions. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com> Cc: "Brown Len" <len.brown@intel.com> LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 03 8月, 2009 3 次提交
-
-
由 Zhao Yakui 提交于
If the memory block size is zero, ignore it and don't do the memory hotplug flowchart. Otherwise it will complain the following warning message: >System RAM resource 0 - ffffffffffffffff cannot be added Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhao Yakui 提交于
Don't treat the generic error as ACPI error code. Otherwise when the generic code is returned, it will complain the following warning messag: >ACPI Exception (acpi_memhotplug-0171): UNKNOWN_STATUS_CODE, Cannot get acpi bus device [20080609] >ACPI: Cannot find driver data > ACPI Error (utglobal-0127): Unknown exception code: 0xFFFFFFED [20080609] > Pid: 85, comm: kacpi_notify Not tainted 2.6.27.19-5-default #1 Call Trace: [<ffffffff8020da29>] show_trace_log_lvl+0x41/0x58 [<ffffffff8049a3da>] dump_stack+0x69/0x6f ..... At the same time when the generic error code is returned, the ACPI_EXCEPTION is replaced by the printk. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
On some machines, a software-initiated SMI causes corruption unless the SMI runs on CPU 0. An SMI can be initiated by any AML, but typically it's done in GPE-related methods that are run via workqueues, so we can avoid the known corruption cases by binding the workqueues to CPU 0. References: http://bugzilla.kernel.org/show_bug.cgi?id=13751 https://bugs.launchpad.net/bugs/157171 https://bugs.launchpad.net/bugs/157691Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 02 8月, 2009 1 次提交
-
-
由 Len Brown 提交于
they were world readable. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 7月, 2009 1 次提交
-
-
This fixes regression (battery "vanishing" on resume) introduced by commit d0c71fe7 ("ACPI Suspend: Enable ACPI during resume if SCI_EN is not set") and also the issue with the "screaming" IRQ 9. Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13745Reported-and-tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Cc: stable@kernel.org Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com> Acked-by: NLen Brown <lenb@kernel.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 28 7月, 2009 1 次提交
-
-
由 Len Brown 提交于
This reverts commit f9ca0584. which caused a regression: http://bugzilla.kernel.org/show_bug.cgi?id=13620Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 22 7月, 2009 1 次提交
-
-
由 Joseph Cihula 提交于
Support for graceful handling of sleep states (S3/S4/S5) after an Intel(R) TXT launch. Without this patch, attempting to place the system in one of the ACPI sleep states (S3/S4/S5) will cause the TXT hardware to treat this as an attack and will cause a system reset, with memory locked. Not only may the subsequent memory scrub take some time, but the platform will be unable to enter the requested power state. This patch calls back into the tboot so that it may properly and securely clean up system state and clear the secrets-in-memory flag, after which it will place the system into the requested sleep state using ACPI information passed by the kernel. arch/x86/kernel/smpboot.c | 2 ++ drivers/acpi/acpica/hwsleep.c | 3 +++ kernel/cpu.c | 7 ++++++- 3 files changed, 11 insertions(+), 1 deletion(-) Signed-off-by: NJoseph Cihula <joseph.cihula@intel.com> Signed-off-by: NShane Wang <shane.wang@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 26 6月, 2009 1 次提交
-
-
由 Troy Moure 提交于
ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468 When the ACPI video driver initializes, it does a namespace walk looking for for supported devices. When we find an appropriate handle, we walk up the ACPI tree looking for a PCI root bus, and then walk back down the PCI bus, assuming that every device inbetween is a P2P bridge. This assumption is not correct, and is reported broken on at least: Dell Latitude E6400 ThinkPad X61 Dell XPS M1330 Add a NULL deref check to prevent boot panics. Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by: NTroy Moure <twmoure@szypr.net> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 24 6月, 2009 7 次提交
-
-
由 Zhao Yakui 提交于
Some BIOS re-use the same processor bus id in different scope: \_SB.SCK0.CPU0 \_SB.SCK1.CPU0 But the (deprecated) /proc/acpi/ interface assumes the bus-id's are unique, resulting in an OOPS when the processor driver is loaded: WARNING: at fs/proc/generic.c:590 proc_register+0x148/0x180() Hardware name: Sunrise Ridge proc_dir_entry 'processor/CPU0' already registered Call Trace: [<ffffffff8023f7ef>] warn_slowpath+0xb1/0xe5 [<ffffffff8036243b>] ? ida_get_new_above+0x190/0x1b1 [<ffffffff803625a8>] ? idr_pre_get+0x5f/0x75 [<ffffffff8030b2f6>] proc_register+0x148/0x180 [<ffffffff8030b4ff>] proc_mkdir_mode+0x3d/0x52 [<ffffffff8030b525>] proc_mkdir+0x11/0x13 [<ffffffffa0014b89>] acpi_processor_start+0x755/0x9bc [processor] Rename the processor device bus id. And the new bus id will be generated as the following format: CPU+ CPU ID For example: If the cpu ID is 5, then the bus ID will be "CPU5". If the CPU ID is 10, then the bus ID will be "CPUA". Yes, this will change the directory names seen in /proc/acpi/processor/* on some systems. Before this patch, those directory names where totally arbitrary strings based on the interal AML device strings. http://bugzilla.kernel.org/show_bug.cgi?id=13612Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=13121Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Now that new interface is available, convert to using it rather than creating a new kernel thread. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhao Yakui 提交于
Sometimes both acpi video and i915 driver are compiled as modules. And there exists the strict dependency between the two drivers. The acpi video bus will be unloaded in course of unloading the i915 driver. If we unload the acpi video driver, then the kernel oops will be triggered. Add the reference count to avoid unloading the ACPI video bus twice. The reference count should be checked before unregistering the acpi video bus. If the reference count is already zero, it won't unregister it again. And after the acpi video bus is already unregistered, the reference count will be set to zero. http://bugzilla.kernel.org/show_bug.cgi?id=13396Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Linux claims Vista compatibility to the BIOS for a number of reasons, but this brings hard lockup on some Sony laptops. Disable Vista compatibility via DMI for these laptops unless we can figure out what Vista is doing for this platform. http://bugzilla.kernel.org/show_bug.cgi?id=12904Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
we used to run the hotplug code in keventd_wq. But when hot removing the ACPI battery device, power_supply_unregister invokes flush_scheduled_work. This causes a deadlock. i.e 1. When dock is unplugged, all the hotplug code is run on kevent_wq. 2. the hotplug code removes all the child devices of dock device. 3. removing the child device may invoke flush_scheduled_work 4. flush_scheduled_work waits until all the work on kevent_wq to be finished, while this will never be true because the hotplug code is running on keventd_wq... Introduce a new workqueue for hotplug in this patch. http://bugzilla.kernel.org/show_bug.cgi?id=13533Tested-by: NPaul Martin <pm@debian.org> Tested-by: NVojtech Gondzala <vojtech.gondzala@gmail.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Create symbol link from backlight class device to ACPI video device. More and more laptops are shipped with multiple ACPI video devices, while we export only one of them to userspace. With this patch applied, we can know which ACPI video device is used by "cat /sys/class/backlight/acpi_video0/device/path". Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 6月, 2009 6 次提交
-
-
由 Pallipadi, Venkatesh 提交于
arch_acpi_processor_cleanup_pdc() in x86 and ia64 results in memory allocated for _PDC objects that is never freed and will cause memory leak in case of physical CPU remove and add. Patch fixes the memory leak by freeing the objects soon after _PDC is evaluated. Reported-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
We never use the PCI device & function number, so remove it to make it clear that it's not needed. Many PCI host bridges don't even appear in config space, so it's meaningless to look at stuff from _ADR, which doesn't exist in that case. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Using list_for_each_entry() makes traversing the root list easier. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
There's no need to search the list to find the acpi_pci_root structure. We saved it as device->driver_data when we added the device. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
By looking up the segment & bus number earlier, we don't have to worry about cleaning up if it fails. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
To find a host bridge's downstream bus number, we currently look at _BBN first. If _BBN returns a bus number we've already seen, we conclude that _BBN was wrong and look for a bus number in _CRS. However, the spec[1] (figure 5-5 and the example in sec 9.12.1) and an ACPI FAQ[2] suggest that the OS should use _CRS to discover the bus number range, and that _BBN is really intended to bootstrap _CRS methods that reference PCI opregions. This patch makes us always look at _CRS first. If _CRS doesn't supply a bus number, we look at _BBN. If _BBN doesn't exist, we default to zero. This makes the behavior consistent regardless of device discovery order. Previously, if A and B had duplicate _BBNs and we found A first, we'd only look at B's _CRS, whereas if we found B first, we'd only look at A's _CRS. I'm told that Windows discovers host bridge bus numbers using _CRS, so it should be fairly safe to rely on this BIOS functionality. This patch also removes two misleading messages: we printed the "Wrong _BBN value, reboot and use option 'pci=noacpi'" message before looking at _CRS, so we would likely find the bus number in _CRS, the system would work fine, and the user would be confused. The "PCI _CRS %d overrides _BBN 0" message incorrectly assumes _BBN was zero, and it's useless anyway because we print the segment/bus number a few lines later. References: [1] http://www.acpi.info/DOWNLOADS/ACPIspec30b.pdf [2] http://www.acpi.info/acpi_faq.htm _BBN/_CRS discussion http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05005_WinHEC05.ppt (slide 17) http://bugzilla.kernel.org/show_bug.cgi?id=1662 ASUS PR-DLS http://bugzilla.kernel.org/show_bug.cgi?id=1127 ASUS PR-DLSW http://bugzilla.kernel.org/show_bug.cgi?id=1741 ASUS PR-DLS533 Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> CC: Shaohua Li <shaohua.li@intel.com> CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 19 6月, 2009 1 次提交
-
-
由 Alex Chiang 提交于
There is no way to interact with a physical PCI slot without sysfs, so encode the dependency and prevent this build error: drivers/pci/slot.c: In function 'pci_hp_create_module_link': drivers/pci/slot.c:327: error: 'module_kset' undeclared This patch _should_ make pci-sysfs.o depend on CONFIG_SYSFS too, but we cannot (yet) because the PCI core merrily assumes the existence of sysfs: drivers/built-in.o: In function `pci_bus_add_device': drivers/pci/bus.c:89: undefined reference to `pci_create_sysfs_dev_files' drivers/built-in.o: In function `pci_stop_dev': drivers/pci/remove.c:24: undefined reference to `pci_remove_sysfs_dev_files' So do the minimal bit for now and figure out how to untangle it later. Reported-by: NRandy Dunlap <randy.dunlap@oracle.com> Acked-by: NRandy Dunlap <randy.dunlap@oracle.com> Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Fix-suggested-by: NMatthew Wilcox <matthew@wil.cx> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 6月, 2009 5 次提交
-
-
由 Len Brown 提交于
cosmetic only. The lapic_timer workaround routines are specific to the lapic_timer, and are not acpi-generic. old: acpi_timer_check_state() acpi_propagate_timer_broadcast() acpi_state_timer_broadcast() new: lapic_timer_check_state() lapic_timer_propagate_broadcast() lapic_timer_state_broadcast() also, simplify the code in acpi_processor_power_verify() so that lapic_timer_check_state() is simply called from one place for all valid C-states, including C1. Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This patch changes the global system notification path so it uses the acpi_handle, not the acpi_device. System notifications often deal with device presence and status change. In these cases, we may not have an acpi_device. For example, we may get a Device Check notification on an object that previously was not present. Since the object was not present, we would not have had an acpi_device for it. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Remove return values from acpi_bus_check_device() and acpi_bus_check_scope() since nobody looks at them. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Remove "status_changed" return from acpi_bus_check_device(). Nobody does anything useful based on its value. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-