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
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
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
6 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 -
Using list_for_each_entry() makes traversing the root list easier.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Chiang
Signed-off-by: Len Brown -
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: Bjorn Helgaas
Signed-off-by: Len Brown -
By looking up the segment & bus number earlier, we don't have to
worry about cleaning up if it fails.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown -
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-DLS533Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Chiang
CC: Shaohua Li
CC: Kenji Kaneshige
Signed-off-by: Len Brown
19 Jun, 2009
1 commit
-
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' undeclaredThis 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: Randy Dunlap
Acked-by: Randy Dunlap
Reported-by: Stephen Rothwell
Fix-suggested-by: Matthew Wilcox
Signed-off-by: Alex Chiang
Signed-off-by: Jesse Barnes
18 Jun, 2009
5 commits
-
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: Len Brown
-
drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used
Signed-off-by: Len Brown
-
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: Bjorn Helgaas
Signed-off-by: Len Brown -
Remove return values from acpi_bus_check_device() and acpi_bus_check_scope()
since nobody looks at them.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown -
Remove "status_changed" return from acpi_bus_check_device(). Nobody
does anything useful based on its value.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown