10 Dec, 2009
1 commit
-
acpi_check_resource_conflict() doesn't change the resource
it operates on, so the res parameter can be marked const.Signed-off-by: Jean Delvare
Signed-off-by: Len Brown
27 Sep, 2009
1 commit
-
The message "ACPI: Device needs an ACPI driver" is misleading. The
device _may_ need an ACPI driver, if the BIOS implemented a custom
API for the device in question (which, AFAIK, can't be checked.) If
not, then either a generic ACPI driver may be used (for example
"thermal"), or nothing can be done (other than a white list).I propose to reword the message to:
ACPI: If an ACPI driver is available for this device, you should use
it instead of the native driverwhich I think is more correct. Comments and suggestions welcome.
I also added a message warning about possible problems and system
instability when users pass acpi_enforce_resources=lax, as suggested
by Len.Signed-off-by: Jean Delvare
Cc: Thomas Renninger
Cc: Alan Jenkins
Signed-off-by: Len Brown
24 Sep, 2009
1 commit
-
set_cpus_allowed() is on the way out; replace it with
set_cpus_allowed_ptr().Reference: http://lkml.org/lkml/2008/11/6/448
Signed-off-by: Bjorn Helgaas
Signed-off-by: Rusty Russell
19 Sep, 2009
2 commits
-
Better to oops and learn about a bug than to silently cover it up.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown -
We had two functions, acpi_os_execute_deferred() and
acpi_os_execute_hp_deferred() that differed only in that the
latter did acpi_os_wait_events_complete(NULL) before executing
the deferred function.This patch consolidates those two functions and uses a flag in
the struct acpi_os_dpc to determine whether to do the wait.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
28 Aug, 2009
1 commit
-
http://bugzilla.kernel.org/show_bug.cgi?id=13620
If the dynamic region is created and added to resource list over and over again,
it has the potential to be a memory leak by growing the list every time.This patch fixes the memory leak, as below
1) add a new field "count" to struct acpi_res_list.
When inserting, if the region(addr, len) is already in the resource
list, we just increase "count", otherwise, the region is inserted
with count=1.When deleting, the "count" is decreased, if it's decreased to 0,
the region is deleted from the resource list.With "count", the region with same address and length can only be
inserted to the resource list once, so prevent potential memory leak.2) add a new function acpi_os_invalidate_address, which is called when
region is deleted.Signed-off-by: Lin Ming
Signed-off-by: Len Brown
03 Aug, 2009
1 commit
-
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
24 Jun, 2009
1 commit
-
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
21 Apr, 2009
1 commit
-
This counter may prove useful in debugging some
spurious interrupt issues seen in the field.Signed-off-by: Len Brown
05 Apr, 2009
1 commit
-
Conflicts:
arch/x86/kernel/cpu/cpufreq/longhaul.cSigned-off-by: Len Brown
03 Apr, 2009
1 commit
-
Enforce strict resource checking - disallowing access by native
drivers to IO ports and memory regions claimed by ACPI firmware.The patch is mainly aimed to block native hwmon drivers from touching
monitoring chips that ACPI thinks it own.If this causes a regression, boot with "acpi_enforce_resources=lax"
which was the previous default.http://bugzilla.kernel.org/show_bug.cgi?id=12376
http://bugzilla.kernel.org/show_bug.cgi?id=12541Signed-off-by: Luca Tettamanti
Acked-by: Pavel Machek
Acked-by: Jean Delvare
Signed-off-by: Len Brown
28 Mar, 2009
1 commit
-
Conflicts:
arch/parisc/kernel/irq.c
arch/x86/include/asm/fixmap_64.h
arch/x86/include/asm/setup.h
kernel/irq/handle.cSemantic merge:
arch/x86/include/asm/fixmap.hSigned-off-by: Ingo Molnar
16 Mar, 2009
1 commit
-
This reverts commit 5ec5d38a1c8af255ffc481c81eef13e9155524b3.
because it caused spurious dmesg warmings.
We'll implement the check for off-limit ports
in a more clever way in the future.http://bugzilla.kernel.org/show_bug.cgi?id=12758
Signed-off-by: Len Brown
23 Feb, 2009
1 commit
-
early_acpi_os_unmap_memory() is an __init function, and
acpi_os_unmap_memory() is allowed to access an __init function
until acpi_gbl_permanent_mmap is set up.Signed-off-by: Jeremy Fitzhardinge
Cc: Len Brown
Signed-off-by: Ingo Molnar
09 Feb, 2009
1 commit
-
to prevent wrongly overwriting fixmap that still want to use.
ACPI used to rely on low mappings being all linearly mapped and
grew a habit: it never really unmapped certain kinds of tables
after use.This can cause problems - for example the hypothetical case
when some spurious access still references it.v2: remove prev_map and prev_size in __apci_map_table
v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
early_acpi_os_unmap_memory
v4: fix typo in one acpi_get_table_with_size callingSigned-off-by: Yinghai Lu
Acked-by: Len Brown
Signed-off-by: Ingo Molnar
07 Feb, 2009
2 commits
-
…isc', 'printk' and 'processor' into release
-
According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing peaces here for the acpi subsystem.Signed-off-by: Frank Seidel
Signed-off-by: Len Brown
04 Feb, 2009
1 commit
-
ACPICA exports acpi_os_validate_address() so the OS
can prevent BIOS AML from accessing specified addresses.Start using this interface to prevent AML from accessing
some well known IO addresses that the OS "owns".Signed-off-by: Len Brown
31 Dec, 2008
1 commit
-
return_ACPI_STATUS is an internal acpica function, replace it with return.
acpi_gbl_permanent_mmap moved from acglobal.h to acpixf.h for external useSigned-off-by: Lin Ming
Signed-off-by: Len Brown
27 Nov, 2008
1 commit
-
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
23 Oct, 2008
3 commits
-
Conflicts:
drivers/acpi/bay.c
drivers/acpi/dock.c
drivers/ata/libata-acpi.cSigned-off-by: Len Brown
-
Conflicts:
drivers/acpi/osl.cSigned-off-by: Len Brown
-
ACPI_DB_ERROR and ACPI_DB_WARN were removed from ACPICA core.
So replace ACPI_DEBUG_PRINT((ACPI_DB_ERROR, ...) with printk(KERN_ERR PREFIX ...)
and ACPI_DEBUG_PRINT((ACPI_DB_WARN, ...) with printk(KERN_WARNING PREFIX ...)We do not use ACPI_ERROR/ACPI_WARNING since they're not exported, see
-------------------------------------------------------------
commit 6468463abd7051fcc29f3ee7c931f9bbbb26f5a4
Author: Len Brown
Date: Mon Jun 26 23:41:38 2006 -0400ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)
Signed-off-by: Len Brown
-------------------------------------------------------------Signed-off-by: Lin Ming
Signed-off-by: Len Brown
11 Oct, 2008
1 commit
-
As of version 2.0, ACPI can return 64-bit integers. The current
acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
Change the argument to take a pointer to an acpi_integer so we support
64-bit integers on all platforms.lenb: replaced use of "acpi_integer" with "unsigned long long"
lenb: fixed bug in acpi_thermal_trips_update()Signed-off-by: Matthew Wilcox
Signed-off-by: Len Brown
24 Sep, 2008
1 commit
-
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
Signed-off-by: Shaohua Li
Signed-off-by: Len Brown
29 Apr, 2008
1 commit
-
Flush kacpi_notify_wq before notify handler is removed,
this can fix a bug which the deferred notify handler is executed
after the notify_handler has already been removed.
http://bugzilla.kernel.org/show_bug.cgi?id=9772Signed-off-by: Zhang Rui
Signed-off-by: Len Brown
17 Apr, 2008
1 commit
-
ACPI currently emulates a timeout for semaphores with calls to
down_trylock and sleep. This produces horrible behaviour in terms of
fairness and excessive wakeups. Now that we have a unified semaphore
implementation, adding a real down_trylock is almost trivial.Signed-off-by: Matthew Wilcox
16 Mar, 2008
1 commit
-
This essentially reverts commit 71fc47a9adf8ee89e5c96a47222915c5485ac437
("ACPI: basic initramfs DSDT override support"), because the code simply
isn't ready.It did ugly things to the init sequence to populate the rootfs image
early, but that just ended up showing other problems with the whole
approach. The fact is, the VFS layer simply isn't initialized this
early, and the relevant ACPI code should either run much later, or this
shouldn't be done at all.For 2.6.25, we'll just pick the latter option. We can revisit this
concept later if necessary.Cc: Dave Hansen
Cc: Tilman Schmidt
Cc: Andrew Morton
Cc: Thomas Renninger
Cc: Eric Piel
Cc: Len Brown
Cc: Christoph Hellwig
Cc: Markus Gaugusch
Signed-off-by: Linus Torvalds
11 Mar, 2008
1 commit
-
Signed-off-by: Jean Delvare
Signed-off-by: Len Brown
14 Feb, 2008
5 commits
-
http://bugzilla.kernel.org/show_bug.cgi?id=9939
Signed-off-by: Len Brown
-
Signed-off-by: Adrian Bunk
Signed-off-by: Len Brown -
Signed-off-by: Adrian Bunk
Acked-by: Eric Piel
Signed-off-by: Len Brown -
The raw_pci_read() interface (as the raw_pci_ops->read() before it)
unconditionally fills in a 32-bit integer return value regardless of the
size of the operation requested.So claiming to take a "void *" is wrong, as is passing in a pointer to
just a byte variable.Noticed by pageexec when enabling -fstack-protector (which needs other
patches too to actually work, but that's a separate issue).Acked-by: Len Brown
Signed-off-by: Linus Torvalds
11 Feb, 2008
1 commit
-
We want to allow different implementations of pci_raw_ops for standard
and extended config space on x86. Rather than clutter generic code with
knowledge of this, we make pci_raw_ops private to x86 and use it to
implement the new raw interface -- raw_pci_read() and raw_pci_write().Signed-off-by: Matthew Wilcox
Signed-off-by: Linus Torvalds
08 Feb, 2008
1 commit
-
Signed-off-by: Len Brown
07 Feb, 2008
4 commits
-
also, address some checkpatch.pl violations
Signed-off-by: Len Brown
-
The acpi_no_initrd_override parameter permits to disable the load of an ACPI
table from the initramfs.Signed-off-by: Eric Piel
Signed-off-by: Len Brown -
Conflicts:
drivers/acpi/scan.c
include/linux/acpi.hSigned-off-by: Len Brown
