21 Sep, 2009
1 commit
-
Signed-off-by: Felipe Contreras
Cc: Vegard Nossum
Cc: Pekka Enberg
Cc: Andrew Morton
Cc: Alok N Kataria
Cc: "Tan Wei Chong"
Cc: Len Brown
Cc: Lin Ming
Cc: Bob Moore
LKML-Reference:
Signed-off-by: Ingo Molnar
16 Sep, 2009
2 commits
-
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (75 commits)
PCI hotplug: clean up acpi_run_hpp()
PCI hotplug: acpiphp: use generic pci_configure_slot()
PCI hotplug: shpchp: use generic pci_configure_slot()
PCI hotplug: pciehp: use generic pci_configure_slot()
PCI hotplug: add pci_configure_slot()
PCI hotplug: clean up acpi_get_hp_params_from_firmware() interface
PCI hotplug: acpiphp: don't cache hotplug_params in acpiphp_bridge
PCI hotplug: acpiphp: remove superfluous _HPP/_HPX evaluation
PCI: Clear saved_state after the state has been restored
PCI PM: Return error codes from pci_pm_resume()
PCI: use dev_printk in quirk messages
PCI / PCIe portdrv: Fix pcie_portdrv_slot_reset()
PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
PCI Hotplug: acpiphp: find bridges the easy way
PCI: pcie portdrv: remove unused variable
PCI / ACPI PM: Propagate wake-up enable for devices w/o ACPI support
ACPI PM: Replace wakeup.prepared with reference counter
PCI PM: Introduce device flag wakeup_prepared
PCI / ACPI PM: Rework some debug messages
PCI PM: Simplify PCI wake-up code
...Fixed up conflict in arch/powerpc/kernel/pci_64.c due to OF device tree
scanning having been moved and merged for the 32- and 64-bit cases. The
'needs_freset' initialization added in 6e19314cc ("PCI/powerpc: support
PCIe fundamental reset") is now in arch/powerpc/kernel/pci_of_scan.c. -
* 'x86-txt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86, intel_txt: clean up the impact on generic code, unbreak non-x86
x86, intel_txt: Handle ACPI_SLEEP without X86_TRAMPOLINE
x86, intel_txt: Fix typos in Kconfig help
x86, intel_txt: Factor out the code for S3 setup
x86, intel_txt: tboot.c needs
intel_txt: Force IOMMU on for Intel TXT launch
x86, intel_txt: Intel TXT Sx shutdown support
x86, intel_txt: Intel TXT reboot/halt shutdown support
x86, intel_txt: Intel TXT boot support
10 Sep, 2009
4 commits
-
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: Matthew Garrett
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
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: Matthew Garrett
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
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: Matthew Garrett
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Jesse Barnes -
We can simplify ACPI drivers if we can tell whether a handle is an
ACPI PCI root or not.Reviewed-by: Bjorn Helgaas
Signed-off-by: Alex Chiang
Signed-off-by: Jesse Barnes
09 Sep, 2009
1 commit
-
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: Tejun Heo
Signed-off-by: Jeff Garzik
02 Sep, 2009
2 commits
-
Conflicts:
arch/x86/kernel/reboot.c
security/KconfigMerge reason: resolve the conflicts, bump up from rc3 to rc8.
Signed-off-by: Ingo Molnar
-
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: Shane Wang
Signed-off-by: H. Peter Anvin
29 Aug, 2009
2 commits
-
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: Keith Packard
Acked-by: Zhang Rui
Signed-off-by: Andrew Morton
Signed-off-by: Len Brown -
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=803
Reported-by: Rezwanul Kabir
Signed-off-by: Lin Ming
Signed-off-by: Bob Moore
Signed-off-by: Len Brown
27 Aug, 2009
3 commits
-
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=13389
Signed-off-by: Frans Pop
Acked-by: Zhang Rui
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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: Frans Pop
Acked-by: Zhang Rui
Cc: Len Brown
Cc: "Rafael J. Wysocki"
Cc: Rusty Russell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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] [] ? printk+0x18/0x1d
> [ 1.581734] [] __early_ioremap+0x74/0x1e9
> [ 1.596898] [] early_ioremap+0x1a/0x1c
> [ 1.611270] [] __acpi_map_table+0x18/0x1a
> [ 1.626451] [] acpi_os_map_memory+0x1d/0x25
> [ 1.642129] [] acpi_tb_verify_table+0x20/0x49
> [ 1.658321] [] acpi_get_table_with_size+0x53/0xa1
> [ 1.675553] [] acpi_get_table+0x10/0x15
> [ 1.690192] [] acpi_processor_init+0x23/0xab
> [ 1.706126] [] do_one_initcall+0x33/0x180
> [ 1.721279] [] ? acpi_processor_init+0x0/0xab
> [ 1.737479] [] ? register_irq_proc+0xaa/0xc0
> [ 1.753411] [] ? init_irq_proc+0x67/0x80
> [ 1.768316] [] kernel_init+0x120/0x176
> [ 1.782678] [] ? kernel_init+0x0/0x176
> [ 1.797062] [] kernel_thread_helper+0x7/0x10
> [ 1.812984] 00000080 + ffe00000that is rather later.
acpi_gbl_permanent_mmap should be set in acpi_early_init()
if acpi is not disabledand we have
> [ 0.000000] ASUS P2B-DS detected: force use of acpi=htjust don't load acpi_processor_init...
Reported-and-tested-by: Jens Rosenboom
Signed-off-by: Yinghai Lu
Acked-by: Ingo Molnar
Cc: Len Brown
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Aug, 2009
1 commit
-
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: Suresh Siddha
Signed-off-by: Venkatesh Pallipadi
Cc: "Pallipadi Venkatesh"
Cc: "Brown Len"
LKML-Reference:
Signed-off-by: Thomas Gleixner
03 Aug, 2009
6 commits
-
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 addedSigned-off-by: Zhao Yakui
Signed-off-by: Len Brown -
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:
[] show_trace_log_lvl+0x41/0x58
[] 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: Zhao Yakui
Signed-off-by: Len Brown -
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: Bjorn Helgaas
Signed-off-by: Len Brown
02 Aug, 2009
2 commits
-
they were world readable.
Signed-off-by: Len Brown
30 Jul, 2009
1 commit
-
This fixes regression (battery "vanishing" on resume) introduced by
commit d0c71fe7ebc180f1b7bc7da1d39a07fc19eec768 ("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=13745
Reported-and-tested-by: Alan Jenkins
Cc: stable@kernel.org
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Len Brown
Signed-off-by: Rafael J. Wysocki
28 Jul, 2009
1 commit
-
This reverts commit f9ca058430333c9a24c5ca926aa445125f88df18.
which caused a regression:
http://bugzilla.kernel.org/show_bug.cgi?id=13620
Signed-off-by: Lin Ming
Signed-off-by: Len Brown
22 Jul, 2009
1 commit
-
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: Joseph Cihula
Signed-off-by: Shane Wang
Signed-off-by: H. Peter Anvin
26 Jun, 2009
1 commit
-
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 M1330Add a NULL deref check to prevent boot panics.
Reported-by: Alessandro Suardi
Signed-off-by: Troy Moure
Signed-off-by: Alex Chiang
Signed-off-by: Len Brown
24 Jun, 2009
9 commits
-
Conflicts:
drivers/platform/x86/eeepc-laptop.cSigned-off-by: Len Brown
-
…bugzilla-13121', 'bugzilla-13396', 'bugzilla-13533', 'bugzilla-13612', 'c3_lock', 'hid-cleanups', 'misc-2.6.31', 'pdc-leak-fix', 'pnpacpi', 'power_nocheck', 'thinkpad_acpi', 'video' and 'wmi' into release
-
Some BIOS re-use the same processor bus id
in different scope:\_SB.SCK0.CPU0
\_SB.SCK1.CPU0But 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:
[] warn_slowpath+0xb1/0xe5
[] ? ida_get_new_above+0x190/0x1b1
[] ? idr_pre_get+0x5f/0x75
[] proc_register+0x148/0x180
[] proc_mkdir_mode+0x3d/0x52
[] proc_mkdir+0x11/0x13
[] 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 IDFor 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=13612
Signed-off-by: Zhao Yakui
Signed-off-by: Len Brown -
http://bugzilla.kernel.org/show_bug.cgi?id=13121
Signed-off-by: Zhang Rui
Signed-off-by: Len Brown -
Now that new interface is available,
convert to using it rather than creating a new kernel thread.Signed-off-by: Zhang Rui
Signed-off-by: Len Brown -
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=13396
Signed-off-by: Zhao Yakui
Acked-by: Zhang Rui
Signed-off-by: Len Brown -
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: Zhang Rui
Signed-off-by: Len Brown -
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: Paul Martin
Tested-by: Vojtech Gondzala
Signed-off-by: Zhang Rui
Reviewed-by: Bjorn Helgaas
Signed-off-by: Len Brown -
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: Zhang Rui
Signed-off-by: Len Brown
23 Jun, 2009
1 commit
-
* 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (74 commits)
PCI: make msi_free_irqs() to use msix_mask_irq() instead of open coded write
PCI: Fix the NIU MSI-X problem in a better way
PCI ASPM: remove get_root_port_link
PCI ASPM: cleanup pcie_aspm_sanity_check
PCI ASPM: remove has_switch field
PCI ASPM: cleanup calc_Lx_latency
PCI ASPM: cleanup pcie_aspm_get_cap_device
PCI ASPM: cleanup clkpm checks
PCI ASPM: cleanup __pcie_aspm_check_state_one
PCI ASPM: cleanup initialization
PCI ASPM: cleanup change input argument of aspm functions
PCI ASPM: cleanup misc in struct pcie_link_state
PCI ASPM: cleanup clkpm state in struct pcie_link_state
PCI ASPM: cleanup latency field in struct pcie_link_state
PCI ASPM: cleanup aspm state field in struct pcie_link_state
PCI ASPM: fix typo in struct pcie_link_state
PCI: drivers/pci/slot.c should depend on CONFIG_SYSFS
PCI: remove redundant __msi_set_enable()
PCI PM: consistently use type bool for wake enable variable
x86/ACPI: Correct maximum allowed _CRS returned resources and warn if exceeded
...
20 Jun, 2009
2 commits
-
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: Bjorn Helgaas
Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Len Brown -
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: Bjorn Helgaas
Reviewed-by: Alex Chiang
Signed-off-by: Len Brown
