2019-05-27 09:55:06 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2005-04-17 02:20:36 +04:00
/*
* acpi_osl . c - OS - dependent functions ( $ Revision : 83 $ )
*
* Copyright ( C ) 2000 Andrew Henroid
* Copyright ( C ) 2001 , 2002 Andy Grover < andrew . grover @ intel . com >
* Copyright ( C ) 2001 , 2002 Paul Diefenbaugh < paul . s . diefenbaugh @ intel . com >
2008-03-14 20:43:13 +03:00
* Copyright ( c ) 2008 Intel Corporation
* Author : Matthew Wilcox < willy @ linux . intel . com >
2005-04-17 02:20:36 +04:00
*/
# include <linux/module.h>
# include <linux/kernel.h>
# include <linux/slab.h>
# include <linux/mm.h>
2012-01-21 06:13:30 +04:00
# include <linux/highmem.h>
2019-07-17 01:12:28 +03:00
# include <linux/lockdep.h>
2005-04-17 02:20:36 +04:00
# include <linux/pci.h>
# include <linux/interrupt.h>
# include <linux/kmod.h>
# include <linux/delay.h>
# include <linux/workqueue.h>
# include <linux/nmi.h>
2007-02-02 19:48:19 +03:00
# include <linux/acpi.h>
2005-04-17 02:20:36 +04:00
# include <linux/efi.h>
2008-02-05 10:31:22 +03:00
# include <linux/ioport.h>
# include <linux/list.h>
2008-03-14 20:43:13 +03:00
# include <linux/jiffies.h>
# include <linux/semaphore.h>
2019-08-20 03:17:51 +03:00
# include <linux/security.h>
2008-03-14 20:43:13 +03:00
# include <asm/io.h>
2016-12-24 22:46:01 +03:00
# include <linux/uaccess.h>
2015-08-28 10:27:14 +03:00
# include <linux/io-64-nonatomic-lo-hi.h>
2008-03-14 20:43:13 +03:00
2018-06-21 16:43:17 +03:00
# include "acpica/accommon.h"
# include "acpica/acnamesp.h"
2013-07-23 12:11:55 +04:00
# include "internal.h"
2005-04-17 02:20:36 +04:00
# define _COMPONENT ACPI_OS_SERVICES
2007-02-13 06:42:12 +03:00
ACPI_MODULE_NAME ( " osl " ) ;
2014-03-13 08:47:39 +04:00
2005-08-05 08:44:28 +04:00
struct acpi_os_dpc {
acpi_osd_exec_callback function ;
void * context ;
2006-11-22 17:55:48 +03:00
struct work_struct work ;
2005-04-17 02:20:36 +04:00
} ;
# ifdef ENABLE_DEBUGGER
# include <linux/kdb.h>
/* stuff for debugger support */
int acpi_in_debugger ;
EXPORT_SYMBOL ( acpi_in_debugger ) ;
2005-08-05 08:44:28 +04:00
# endif /*ENABLE_DEBUGGER */
2005-04-17 02:20:36 +04:00
2011-12-09 06:05:54 +04:00
static int ( * __acpi_os_prepare_sleep ) ( u8 sleep_state , u32 pm1a_ctrl ,
u32 pm1b_ctrl ) ;
2013-07-30 16:24:52 +04:00
static int ( * __acpi_os_prepare_extended_sleep ) ( u8 sleep_state , u32 val_a ,
u32 val_b ) ;
2011-12-09 06:05:54 +04:00
2005-04-17 02:20:36 +04:00
static acpi_osd_handler acpi_irq_handler ;
static void * acpi_irq_context ;
static struct workqueue_struct * kacpid_wq ;
ACPI: created a dedicated workqueue for notify() execution
HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.
Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some variable
and lets the loop above break.
In the current ACPI implementation Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% cpu utilization by kacpid for several seconds
or more.
To prevent all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel stack
overflow.
First attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.
Second attempt was done by me, I created a new thread for each Notify
event. This worked OK on HP nx machines, but broke Linus' Compaq
n620c, by producing threads with a speed what they stopped the machine
completely. Thus this patch was reverted from 18-rc2 as I remember.
I re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).
Now you see last variant which adds yield() to every GPE execution.
http://bugzilla.kernel.org/show_bug.cgi?id=5534
http://bugzilla.kernel.org/show_bug.cgi?id=8385
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-05-10 07:31:03 +04:00
static struct workqueue_struct * kacpi_notify_wq ;
2013-01-22 01:20:47 +04:00
static struct workqueue_struct * kacpi_hotplug_wq ;
2015-08-05 11:23:51 +03:00
static bool acpi_os_initialized ;
2015-10-24 20:02:19 +03:00
unsigned int acpi_sci_irq = INVALID_ACPI_IRQ ;
2016-12-14 10:04:46 +03:00
bool acpi_permanent_mmap = false ;
2005-04-17 02:20:36 +04:00
2010-10-22 00:23:53 +04:00
/*
* This list of permanent mappings is for memory that may be accessed from
* interrupt context , where we can ' t do the ioremap ( ) .
*/
struct acpi_ioremap {
struct list_head list ;
void __iomem * virt ;
acpi_physical_address phys ;
acpi_size size ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
union {
unsigned long refcount ;
struct rcu_work rwork ;
} track ;
2010-10-22 00:23:53 +04:00
} ;
static LIST_HEAD ( acpi_ioremaps ) ;
2011-02-09 01:37:42 +03:00
static DEFINE_MUTEX ( acpi_ioremap_lock ) ;
2019-07-17 01:12:28 +03:00
# define acpi_ioremap_lock_held() lock_is_held(&acpi_ioremap_lock.dep_map)
2010-10-22 00:23:53 +04:00
2011-11-08 03:23:27 +04:00
static void __init acpi_request_region ( struct acpi_generic_address * gas ,
2007-01-19 02:42:55 +03:00
unsigned int length , char * desc )
{
2011-11-08 03:23:27 +04:00
u64 addr ;
/* Handle possible alignment issues */
memcpy ( & addr , & gas - > address , sizeof ( addr ) ) ;
if ( ! addr | | ! length )
2007-01-19 02:42:55 +03:00
return ;
ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage
This effectively reverts the following three commits:
7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()
(commit b9a5e5e18fbf introduced regressions some of which, but not
all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
was a fixup on top of the latter) and causes ACPI fixed hardware
resources to be reserved at the fs_initcall_sync stage of system
initialization.
The story is as follows. First, a boot regression was reported due
to an apparent resource reservation ordering change after a commit
that shouldn't lead to such changes. Investigation led to the
conclusion that the problem happened because acpi_reserve_resources()
was executed at the device_initcall() stage of system initialization
which wasn't strictly ordered with respect to driver initialization
(and with respect to the initialization of the pcieport driver in
particular), so a random change causing the device initcalls to be
run in a different order might break things.
The response to that was to attempt to run acpi_reserve_resources()
as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
However, that turned out to be too early, because it caused resource
reservations made by the PNP system driver to fail on at least one
system and that failure was addressed by commit 0f1b414d1907.
That fix still turned out to be insufficient, though, because
calling acpi_reserve_resources() before the fs_initcall stage of
system initialization caused a boot regression to happen on the
eCAFE EC-800-H20G/S netbook. That meant that we only could call
acpi_reserve_resources() at the fs_initcall initialization stage
or later, but then we might just as well call it after the PNP
initalization in which case commit 0f1b414d1907 wouldn't be
necessary any more.
For this reason, the changes made by commit 0f1b414d1907 are reverted
(along with a memory leak fixup on top of that commit), the changes
made by commit b9a5e5e18fbf that went too far are reverted too and
acpi_reserve_resources() is changed into fs_initcall_sync, which
will cause it to be executed after the PNP subsystem initialization
(which is an fs_initcall) and before device initcalls (including
the pcieport driver initialization) which should avoid the initial
issue.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
Link: http://marc.info/?t=143092384600002&r=1&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: Roland Dreier <roland@purestorage.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-04 04:09:03 +03:00
/* Resources are never freed */
if ( gas - > space_id = = ACPI_ADR_SPACE_SYSTEM_IO )
request_region ( addr , length , desc ) ;
else if ( gas - > space_id = = ACPI_ADR_SPACE_SYSTEM_MEMORY )
request_mem_region ( addr , length , desc ) ;
2007-01-19 02:42:55 +03:00
}
ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage
This effectively reverts the following three commits:
7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()
(commit b9a5e5e18fbf introduced regressions some of which, but not
all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
was a fixup on top of the latter) and causes ACPI fixed hardware
resources to be reserved at the fs_initcall_sync stage of system
initialization.
The story is as follows. First, a boot regression was reported due
to an apparent resource reservation ordering change after a commit
that shouldn't lead to such changes. Investigation led to the
conclusion that the problem happened because acpi_reserve_resources()
was executed at the device_initcall() stage of system initialization
which wasn't strictly ordered with respect to driver initialization
(and with respect to the initialization of the pcieport driver in
particular), so a random change causing the device initcalls to be
run in a different order might break things.
The response to that was to attempt to run acpi_reserve_resources()
as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
However, that turned out to be too early, because it caused resource
reservations made by the PNP system driver to fail on at least one
system and that failure was addressed by commit 0f1b414d1907.
That fix still turned out to be insufficient, though, because
calling acpi_reserve_resources() before the fs_initcall stage of
system initialization caused a boot regression to happen on the
eCAFE EC-800-H20G/S netbook. That meant that we only could call
acpi_reserve_resources() at the fs_initcall initialization stage
or later, but then we might just as well call it after the PNP
initalization in which case commit 0f1b414d1907 wouldn't be
necessary any more.
For this reason, the changes made by commit 0f1b414d1907 are reverted
(along with a memory leak fixup on top of that commit), the changes
made by commit b9a5e5e18fbf that went too far are reverted too and
acpi_reserve_resources() is changed into fs_initcall_sync, which
will cause it to be executed after the PNP subsystem initialization
(which is an fs_initcall) and before device initcalls (including
the pcieport driver initialization) which should avoid the initial
issue.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
Link: http://marc.info/?t=143092384600002&r=1&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: Roland Dreier <roland@purestorage.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-04 04:09:03 +03:00
static int __init acpi_reserve_resources ( void )
2007-01-19 02:42:55 +03:00
{
2007-02-03 09:38:16 +03:00
acpi_request_region ( & acpi_gbl_FADT . xpm1a_event_block , acpi_gbl_FADT . pm1_event_length ,
2007-01-19 02:42:55 +03:00
" ACPI PM1a_EVT_BLK " ) ;
2007-02-03 09:38:16 +03:00
acpi_request_region ( & acpi_gbl_FADT . xpm1b_event_block , acpi_gbl_FADT . pm1_event_length ,
2007-01-19 02:42:55 +03:00
" ACPI PM1b_EVT_BLK " ) ;
2007-02-03 09:38:16 +03:00
acpi_request_region ( & acpi_gbl_FADT . xpm1a_control_block , acpi_gbl_FADT . pm1_control_length ,
2007-01-19 02:42:55 +03:00
" ACPI PM1a_CNT_BLK " ) ;
2007-02-03 09:38:16 +03:00
acpi_request_region ( & acpi_gbl_FADT . xpm1b_control_block , acpi_gbl_FADT . pm1_control_length ,
2007-01-19 02:42:55 +03:00
" ACPI PM1b_CNT_BLK " ) ;
2007-02-03 09:38:16 +03:00
if ( acpi_gbl_FADT . pm_timer_length = = 4 )
acpi_request_region ( & acpi_gbl_FADT . xpm_timer_block , 4 , " ACPI PM_TMR " ) ;
2007-01-19 02:42:55 +03:00
2007-02-03 09:38:16 +03:00
acpi_request_region ( & acpi_gbl_FADT . xpm2_control_block , acpi_gbl_FADT . pm2_control_length ,
2007-01-19 02:42:55 +03:00
" ACPI PM2_CNT_BLK " ) ;
/* Length of GPE blocks must be a non-negative multiple of 2 */
2007-02-03 09:38:16 +03:00
if ( ! ( acpi_gbl_FADT . gpe0_block_length & 0x1 ) )
acpi_request_region ( & acpi_gbl_FADT . xgpe0_block ,
acpi_gbl_FADT . gpe0_block_length , " ACPI GPE0_BLK " ) ;
2007-01-19 02:42:55 +03:00
2007-02-03 09:38:16 +03:00
if ( ! ( acpi_gbl_FADT . gpe1_block_length & 0x1 ) )
acpi_request_region ( & acpi_gbl_FADT . xgpe1_block ,
acpi_gbl_FADT . gpe1_block_length , " ACPI GPE1_BLK " ) ;
ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage
This effectively reverts the following three commits:
7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()
(commit b9a5e5e18fbf introduced regressions some of which, but not
all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
was a fixup on top of the latter) and causes ACPI fixed hardware
resources to be reserved at the fs_initcall_sync stage of system
initialization.
The story is as follows. First, a boot regression was reported due
to an apparent resource reservation ordering change after a commit
that shouldn't lead to such changes. Investigation led to the
conclusion that the problem happened because acpi_reserve_resources()
was executed at the device_initcall() stage of system initialization
which wasn't strictly ordered with respect to driver initialization
(and with respect to the initialization of the pcieport driver in
particular), so a random change causing the device initcalls to be
run in a different order might break things.
The response to that was to attempt to run acpi_reserve_resources()
as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
However, that turned out to be too early, because it caused resource
reservations made by the PNP system driver to fail on at least one
system and that failure was addressed by commit 0f1b414d1907.
That fix still turned out to be insufficient, though, because
calling acpi_reserve_resources() before the fs_initcall stage of
system initialization caused a boot regression to happen on the
eCAFE EC-800-H20G/S netbook. That meant that we only could call
acpi_reserve_resources() at the fs_initcall initialization stage
or later, but then we might just as well call it after the PNP
initalization in which case commit 0f1b414d1907 wouldn't be
necessary any more.
For this reason, the changes made by commit 0f1b414d1907 are reverted
(along with a memory leak fixup on top of that commit), the changes
made by commit b9a5e5e18fbf that went too far are reverted too and
acpi_reserve_resources() is changed into fs_initcall_sync, which
will cause it to be executed after the PNP subsystem initialization
(which is an fs_initcall) and before device initcalls (including
the pcieport driver initialization) which should avoid the initial
issue.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
Link: http://marc.info/?t=143092384600002&r=1&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: Roland Dreier <roland@purestorage.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-04 04:09:03 +03:00
return 0 ;
2007-01-19 02:42:55 +03:00
}
ACPI / PNP: Reserve ACPI resources at the fs_initcall_sync stage
This effectively reverts the following three commits:
7bc10388ccdd ACPI / resources: free memory on error in add_region_before()
0f1b414d1907 ACPI / PNP: Avoid conflicting resource reservations
b9a5e5e18fbf ACPI / init: Fix the ordering of acpi_reserve_resources()
(commit b9a5e5e18fbf introduced regressions some of which, but not
all, were addressed by commit 0f1b414d1907 and commit 7bc10388ccdd
was a fixup on top of the latter) and causes ACPI fixed hardware
resources to be reserved at the fs_initcall_sync stage of system
initialization.
The story is as follows. First, a boot regression was reported due
to an apparent resource reservation ordering change after a commit
that shouldn't lead to such changes. Investigation led to the
conclusion that the problem happened because acpi_reserve_resources()
was executed at the device_initcall() stage of system initialization
which wasn't strictly ordered with respect to driver initialization
(and with respect to the initialization of the pcieport driver in
particular), so a random change causing the device initcalls to be
run in a different order might break things.
The response to that was to attempt to run acpi_reserve_resources()
as soon as we knew that ACPI would be in use (commit b9a5e5e18fbf).
However, that turned out to be too early, because it caused resource
reservations made by the PNP system driver to fail on at least one
system and that failure was addressed by commit 0f1b414d1907.
That fix still turned out to be insufficient, though, because
calling acpi_reserve_resources() before the fs_initcall stage of
system initialization caused a boot regression to happen on the
eCAFE EC-800-H20G/S netbook. That meant that we only could call
acpi_reserve_resources() at the fs_initcall initialization stage
or later, but then we might just as well call it after the PNP
initalization in which case commit 0f1b414d1907 wouldn't be
necessary any more.
For this reason, the changes made by commit 0f1b414d1907 are reverted
(along with a memory leak fixup on top of that commit), the changes
made by commit b9a5e5e18fbf that went too far are reverted too and
acpi_reserve_resources() is changed into fs_initcall_sync, which
will cause it to be executed after the PNP subsystem initialization
(which is an fs_initcall) and before device initcalls (including
the pcieport driver initialization) which should avoid the initial
issue.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100581
Link: http://marc.info/?t=143092384600002&r=1&w=2
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831
Link: http://marc.info/?t=143389402600001&r=1&w=2
Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()"
Reported-by: Roland Dreier <roland@purestorage.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-04 04:09:03 +03:00
fs_initcall_sync ( acpi_reserve_resources ) ;
2007-01-19 02:42:55 +03:00
2005-08-05 08:44:28 +04:00
void acpi_os_printf ( const char * fmt , . . . )
2005-04-17 02:20:36 +04:00
{
va_list args ;
va_start ( args , fmt ) ;
acpi_os_vprintf ( fmt , args ) ;
va_end ( args ) ;
}
2015-12-03 05:43:14 +03:00
EXPORT_SYMBOL ( acpi_os_printf ) ;
2005-08-05 08:44:28 +04:00
void acpi_os_vprintf ( const char * fmt , va_list args )
2005-04-17 02:20:36 +04:00
{
static char buffer [ 512 ] ;
2005-08-05 08:44:28 +04:00
2005-04-17 02:20:36 +04:00
vsprintf ( buffer , fmt , args ) ;
# ifdef ENABLE_DEBUGGER
if ( acpi_in_debugger ) {
kdb_printf ( " %s " , buffer ) ;
} else {
2016-10-12 21:50:34 +03:00
if ( printk_get_level ( buffer ) )
printk ( " %s " , buffer ) ;
else
printk ( KERN_CONT " %s " , buffer ) ;
2005-04-17 02:20:36 +04:00
}
# else
2016-10-12 21:50:34 +03:00
if ( acpi_debugger_write_log ( buffer ) < 0 ) {
if ( printk_get_level ( buffer ) )
printk ( " %s " , buffer ) ;
else
printk ( KERN_CONT " %s " , buffer ) ;
}
2005-04-17 02:20:36 +04:00
# endif
}
2011-07-15 02:05:21 +04:00
# ifdef CONFIG_KEXEC
static unsigned long acpi_rsdp ;
static int __init setup_acpi_rsdp ( char * arg )
{
2016-12-02 20:42:46 +03:00
return kstrtoul ( arg , 16 , & acpi_rsdp ) ;
2011-07-15 02:05:21 +04:00
}
early_param ( " acpi_rsdp " , setup_acpi_rsdp ) ;
# endif
2007-02-02 19:48:19 +03:00
acpi_physical_address __init acpi_os_get_root_pointer ( void )
2005-04-17 02:20:36 +04:00
{
2018-02-19 13:09:04 +03:00
acpi_physical_address pa ;
2016-12-02 20:42:47 +03:00
2011-07-15 02:05:21 +04:00
# ifdef CONFIG_KEXEC
2019-08-20 03:17:51 +03:00
/*
* We may have been provided with an RSDP on the command line ,
* but if a malicious user has done so they may be pointing us
* at modified ACPI tables that could alter kernel behaviour -
* so , we check the lockdown status before making use of
* it . If we trust it then also stash it in an architecture
* specific location ( if appropriate ) so it can be carried
* over further kexec ( ) s .
*/
if ( acpi_rsdp & & ! security_locked_down ( LOCKDOWN_ACPI_TABLES ) ) {
acpi_arch_set_root_pointer ( acpi_rsdp ) ;
2011-07-15 02:05:21 +04:00
return acpi_rsdp ;
2019-08-20 03:17:51 +03:00
}
2011-07-15 02:05:21 +04:00
# endif
2018-02-19 13:09:04 +03:00
pa = acpi_arch_get_root_pointer ( ) ;
if ( pa )
return pa ;
2011-07-15 02:05:21 +04:00
2012-11-14 13:42:35 +04:00
if ( efi_enabled ( EFI_CONFIG_TABLES ) ) {
2006-03-26 13:37:08 +04:00
if ( efi . acpi20 ! = EFI_INVALID_TABLE_ADDR )
2007-02-02 19:48:19 +03:00
return efi . acpi20 ;
2016-12-02 20:42:47 +03:00
if ( efi . acpi ! = EFI_INVALID_TABLE_ADDR )
2007-02-02 19:48:19 +03:00
return efi . acpi ;
2016-12-02 20:42:47 +03:00
pr_err ( PREFIX " System description tables not found \n " ) ;
2014-07-18 14:02:52 +04:00
} else if ( IS_ENABLED ( CONFIG_ACPI_LEGACY_TABLES_LOOKUP ) ) {
2007-11-24 04:08:02 +03:00
acpi_find_root_pointer ( & pa ) ;
}
2014-07-18 14:02:52 +04:00
2016-12-02 20:42:47 +03:00
return pa ;
2005-04-17 02:20:36 +04:00
}
2010-10-22 00:24:09 +04:00
/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
2010-10-22 00:24:14 +04:00
static struct acpi_ioremap *
acpi_map_lookup ( acpi_physical_address phys , acpi_size size )
2010-10-22 00:23:53 +04:00
{
struct acpi_ioremap * map ;
2019-07-17 01:12:28 +03:00
list_for_each_entry_rcu ( map , & acpi_ioremaps , list , acpi_ioremap_lock_held ( ) )
2010-10-22 00:23:53 +04:00
if ( map - > phys < = phys & &
phys + size < = map - > phys + map - > size )
2010-10-22 00:24:14 +04:00
return map ;
return NULL ;
}
/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
static void __iomem *
acpi_map_vaddr_lookup ( acpi_physical_address phys , unsigned int size )
{
struct acpi_ioremap * map ;
map = acpi_map_lookup ( phys , size ) ;
if ( map )
return map - > virt + ( phys - map - > phys ) ;
2010-10-22 00:23:53 +04:00
return NULL ;
}
2011-02-09 01:38:25 +03:00
void __iomem * acpi_os_get_iomem ( acpi_physical_address phys , unsigned int size )
{
struct acpi_ioremap * map ;
void __iomem * virt = NULL ;
mutex_lock ( & acpi_ioremap_lock ) ;
map = acpi_map_lookup ( phys , size ) ;
if ( map ) {
virt = map - > virt + ( phys - map - > phys ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
map - > track . refcount + + ;
2011-02-09 01:38:25 +03:00
}
mutex_unlock ( & acpi_ioremap_lock ) ;
return virt ;
}
EXPORT_SYMBOL_GPL ( acpi_os_get_iomem ) ;
2010-10-22 00:24:09 +04:00
/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */
2010-10-22 00:23:53 +04:00
static struct acpi_ioremap *
acpi_map_lookup_virt ( void __iomem * virt , acpi_size size )
{
struct acpi_ioremap * map ;
2019-07-17 01:12:28 +03:00
list_for_each_entry_rcu ( map , & acpi_ioremaps , list , acpi_ioremap_lock_held ( ) )
2010-10-22 00:24:14 +04:00
if ( map - > virt < = virt & &
virt + size < = map - > virt + map - > size )
2010-10-22 00:23:53 +04:00
return map ;
return NULL ;
}
2015-03-24 17:02:35 +03:00
# if defined(CONFIG_IA64) || defined(CONFIG_ARM64)
2012-01-21 06:13:30 +04:00
/* ioremap will take care of cache attributes */
# define should_use_kmap(pfn) 0
2015-03-24 17:02:35 +03:00
# else
# define should_use_kmap(pfn) page_is_ram(pfn)
2012-01-21 06:13:30 +04:00
# endif
static void __iomem * acpi_map ( acpi_physical_address pg_off , unsigned long pg_sz )
{
unsigned long pfn ;
pfn = pg_off > > PAGE_SHIFT ;
if ( should_use_kmap ( pfn ) ) {
if ( pg_sz > PAGE_SIZE )
return NULL ;
return ( void __iomem __force * ) kmap ( pfn_to_page ( pfn ) ) ;
} else
return acpi_os_ioremap ( pg_off , pg_sz ) ;
}
static void acpi_unmap ( acpi_physical_address pg_off , void __iomem * vaddr )
{
unsigned long pfn ;
pfn = pg_off > > PAGE_SHIFT ;
2012-02-24 15:41:53 +04:00
if ( should_use_kmap ( pfn ) )
2012-01-21 06:13:30 +04:00
kunmap ( pfn_to_page ( pfn ) ) ;
else
iounmap ( vaddr ) ;
}
2016-01-02 05:10:29 +03:00
/**
* acpi_os_map_iomem - Get a virtual address for a given physical address range .
* @ phys : Start of the physical address range to map .
* @ size : Size of the physical address range to map .
*
* Look up the given physical address range in the list of existing ACPI memory
* mappings . If found , get a reference to it and return a pointer to it ( its
* virtual address ) . If not found , map it , add it to that list and return a
* pointer to it .
*
2016-12-14 10:04:46 +03:00
* During early init ( when acpi_permanent_mmap has not been set yet ) this
2016-01-02 05:10:29 +03:00
* routine simply calls __acpi_map_table ( ) to get the job done .
*/
2019-06-03 23:28:35 +03:00
void __iomem __ref
* acpi_os_map_iomem ( acpi_physical_address phys , acpi_size size )
2005-04-17 02:20:36 +04:00
{
2011-02-09 01:38:05 +03:00
struct acpi_ioremap * map ;
2010-10-22 00:23:53 +04:00
void __iomem * virt ;
2011-01-20 00:27:14 +03:00
acpi_physical_address pg_off ;
acpi_size pg_sz ;
2010-10-22 00:23:53 +04:00
2006-03-26 13:37:10 +04:00
if ( phys > ULONG_MAX ) {
printk ( KERN_ERR PREFIX " Cannot map memory that high \n " ) ;
2007-02-14 03:11:36 +03:00
return NULL ;
2005-04-17 02:20:36 +04:00
}
2010-10-22 00:23:53 +04:00
2016-12-14 10:04:46 +03:00
if ( ! acpi_permanent_mmap )
2007-02-02 19:48:19 +03:00
return __acpi_map_table ( ( unsigned long ) phys , size ) ;
2010-10-22 00:23:53 +04:00
2011-02-09 01:38:05 +03:00
mutex_lock ( & acpi_ioremap_lock ) ;
/* Check if there's a suitable mapping already. */
map = acpi_map_lookup ( phys , size ) ;
if ( map ) {
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
map - > track . refcount + + ;
2011-02-09 01:38:05 +03:00
goto out ;
}
2010-10-22 00:23:53 +04:00
map = kzalloc ( sizeof ( * map ) , GFP_KERNEL ) ;
2011-02-09 01:38:05 +03:00
if ( ! map ) {
mutex_unlock ( & acpi_ioremap_lock ) ;
2010-10-22 00:23:53 +04:00
return NULL ;
2011-02-09 01:38:05 +03:00
}
2010-10-22 00:23:53 +04:00
2010-10-22 00:24:14 +04:00
pg_off = round_down ( phys , PAGE_SIZE ) ;
pg_sz = round_up ( phys + size , PAGE_SIZE ) - pg_off ;
ACPI: ioremap: avoid redundant rounding to OS page size
The arm64 implementation of acpi_os_ioremap() was recently updated to
tighten the checks around which parts of memory are permitted to be
mapped by ACPI code, which generally only needs access to memory regions
that are statically described by firmware, and any attempts to access
memory that is in active use by the OS is generally a bug or a hacking
attempt. This tightening is based on the EFI memory map, which describes
all memory in the system.
The AArch64 architecture permits page sizes of 16k and 64k in addition
to the EFI default, which is 4k, which means that the EFI memory map may
describe regions that cannot be mapped seamlessly if the OS page size is
greater than 4k. This is usually not a problem, given that the EFI spec
does not permit memory regions requiring different memory attributes to
share a 64k page frame, and so the usual rounding to page size performed
by ioremap() is sufficient to deal with this. However, this rounding does
complicate our EFI memory map permission check, due to the loss of
information that occurs when several small regions share a single 64k
page frame (where rounding each of them will result in the same 64k
single page region).
However, due to the fact that the region check occurs *before* the call
to ioremap() where the necessary rounding is performed, we can deal
with this issue simply by removing the redundant rounding performed by
acpi_os_map_iomem(), as it appears to be the only place where the
arguments to a call to acpi_os_ioremap() are rounded up. So omit the
rounding in the call, and instead, apply the necessary masking when
assigning the map->virt member.
Fixes: 1583052d111f ("arm64/acpi: disallow AML memory opregions to access kernel memory")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-08-18 12:13:53 +03:00
virt = acpi_map ( phys , size ) ;
2010-10-22 00:23:53 +04:00
if ( ! virt ) {
2011-02-09 01:38:05 +03:00
mutex_unlock ( & acpi_ioremap_lock ) ;
2010-10-22 00:23:53 +04:00
kfree ( map ) ;
return NULL ;
}
INIT_LIST_HEAD ( & map - > list ) ;
ACPI: ioremap: avoid redundant rounding to OS page size
The arm64 implementation of acpi_os_ioremap() was recently updated to
tighten the checks around which parts of memory are permitted to be
mapped by ACPI code, which generally only needs access to memory regions
that are statically described by firmware, and any attempts to access
memory that is in active use by the OS is generally a bug or a hacking
attempt. This tightening is based on the EFI memory map, which describes
all memory in the system.
The AArch64 architecture permits page sizes of 16k and 64k in addition
to the EFI default, which is 4k, which means that the EFI memory map may
describe regions that cannot be mapped seamlessly if the OS page size is
greater than 4k. This is usually not a problem, given that the EFI spec
does not permit memory regions requiring different memory attributes to
share a 64k page frame, and so the usual rounding to page size performed
by ioremap() is sufficient to deal with this. However, this rounding does
complicate our EFI memory map permission check, due to the loss of
information that occurs when several small regions share a single 64k
page frame (where rounding each of them will result in the same 64k
single page region).
However, due to the fact that the region check occurs *before* the call
to ioremap() where the necessary rounding is performed, we can deal
with this issue simply by removing the redundant rounding performed by
acpi_os_map_iomem(), as it appears to be the only place where the
arguments to a call to acpi_os_ioremap() are rounded up. So omit the
rounding in the call, and instead, apply the necessary masking when
assigning the map->virt member.
Fixes: 1583052d111f ("arm64/acpi: disallow AML memory opregions to access kernel memory")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-08-18 12:13:53 +03:00
map - > virt = ( void __iomem __force * ) ( ( unsigned long ) virt & PAGE_MASK ) ;
2010-10-22 00:24:14 +04:00
map - > phys = pg_off ;
map - > size = pg_sz ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
map - > track . refcount = 1 ;
2010-10-22 00:23:53 +04:00
2010-10-22 00:24:09 +04:00
list_add_tail_rcu ( & map - > list , & acpi_ioremaps ) ;
2010-10-22 00:23:53 +04:00
2014-05-20 11:39:41 +04:00
out :
2011-02-09 01:38:05 +03:00
mutex_unlock ( & acpi_ioremap_lock ) ;
2010-10-22 00:24:14 +04:00
return map - > virt + ( phys - map - > phys ) ;
2005-04-17 02:20:36 +04:00
}
2014-05-20 11:39:41 +04:00
EXPORT_SYMBOL_GPL ( acpi_os_map_iomem ) ;
2016-08-03 00:03:33 +03:00
void * __ref acpi_os_map_memory ( acpi_physical_address phys , acpi_size size )
2014-05-20 11:39:41 +04:00
{
return ( void * ) acpi_os_map_iomem ( phys , size ) ;
}
2006-01-08 12:03:15 +03:00
EXPORT_SYMBOL_GPL ( acpi_os_map_memory ) ;
2005-04-17 02:20:36 +04:00
2020-07-02 15:14:05 +03:00
static void acpi_os_map_remove ( struct work_struct * work )
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
{
2020-07-02 15:14:05 +03:00
struct acpi_ioremap * map = container_of ( to_rcu_work ( work ) ,
struct acpi_ioremap ,
track . rwork ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
acpi_unmap ( map - > phys , map - > virt ) ;
kfree ( map ) ;
}
2019-11-20 08:47:27 +03:00
/* Must be called with mutex_lock(&acpi_ioremap_lock) */
2020-07-02 15:13:46 +03:00
static void acpi_os_drop_map_ref ( struct acpi_ioremap * map )
2010-10-22 00:24:14 +04:00
{
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
if ( - - map - > track . refcount )
2020-07-02 15:13:46 +03:00
return ;
2019-11-20 08:47:27 +03:00
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
list_del_rcu ( & map - > list ) ;
2020-07-02 15:14:05 +03:00
INIT_RCU_WORK ( & map - > track . rwork , acpi_os_map_remove ) ;
2020-07-02 15:13:46 +03:00
queue_rcu_work ( system_wq , & map - > track . rwork ) ;
2010-10-22 00:24:14 +04:00
}
2020-07-02 15:13:46 +03:00
/**
* acpi_os_unmap_iomem - Drop a memory mapping reference .
* @ virt : Start of the address range to drop a reference to .
* @ size : Size of the address range to drop a reference to .
*
* Look up the given virtual address range in the list of existing ACPI memory
* mappings , drop a reference to it and if there are no more active references
* to it , queue it up for later removal .
*
* During early init ( when acpi_permanent_mmap has not been set yet ) this
* routine simply calls __acpi_unmap_table ( ) to get the job done . Since
* __acpi_unmap_table ( ) is an __init function , the __ref annotation is needed
* here .
*/
void __ref acpi_os_unmap_iomem ( void __iomem * virt , acpi_size size )
2005-04-17 02:20:36 +04:00
{
2010-10-22 00:23:53 +04:00
struct acpi_ioremap * map ;
2016-12-14 10:04:46 +03:00
if ( ! acpi_permanent_mmap ) {
2009-02-08 02:39:41 +03:00
__acpi_unmap_table ( virt , size ) ;
2010-10-22 00:23:53 +04:00
return ;
}
2011-02-09 01:37:42 +03:00
mutex_lock ( & acpi_ioremap_lock ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
2010-10-22 00:23:53 +04:00
map = acpi_map_lookup_virt ( virt , size ) ;
if ( ! map ) {
2011-02-09 01:37:42 +03:00
mutex_unlock ( & acpi_ioremap_lock ) ;
2011-02-09 01:37:53 +03:00
WARN ( true , PREFIX " %s: bad address %p \n " , __func__ , virt ) ;
2010-10-22 00:23:53 +04:00
return ;
}
2020-07-02 15:13:46 +03:00
acpi_os_drop_map_ref ( map ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
2011-02-09 01:37:42 +03:00
mutex_unlock ( & acpi_ioremap_lock ) ;
2005-04-17 02:20:36 +04:00
}
2014-05-20 11:39:41 +04:00
EXPORT_SYMBOL_GPL ( acpi_os_unmap_iomem ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
/**
* acpi_os_unmap_memory - Drop a memory mapping reference .
* @ virt : Start of the address range to drop a reference to .
* @ size : Size of the address range to drop a reference to .
*/
2014-05-20 11:39:41 +04:00
void __ref acpi_os_unmap_memory ( void * virt , acpi_size size )
{
2020-07-02 15:13:46 +03:00
acpi_os_unmap_iomem ( ( void __iomem * ) virt , size ) ;
2014-05-20 11:39:41 +04:00
}
2006-01-08 12:03:15 +03:00
EXPORT_SYMBOL_GPL ( acpi_os_unmap_memory ) ;
2005-04-17 02:20:36 +04:00
2020-09-11 15:59:35 +03:00
void __iomem * acpi_os_map_generic_address ( struct acpi_generic_address * gas )
2010-10-22 00:23:59 +04:00
{
2011-11-08 03:23:27 +04:00
u64 addr ;
2010-10-22 00:23:59 +04:00
2011-11-08 03:23:27 +04:00
if ( gas - > space_id ! = ACPI_ADR_SPACE_SYSTEM_MEMORY )
2020-09-11 15:59:35 +03:00
return NULL ;
2010-10-22 00:23:59 +04:00
2011-11-08 03:23:27 +04:00
/* Handle possible alignment issues */
memcpy ( & addr , & gas - > address , sizeof ( addr ) ) ;
if ( ! addr | | ! gas - > bit_width )
2020-09-11 15:59:35 +03:00
return NULL ;
2010-10-22 00:23:59 +04:00
2020-09-11 15:59:35 +03:00
return acpi_os_map_iomem ( addr , gas - > bit_width / 8 ) ;
2010-10-22 00:23:59 +04:00
}
2011-11-08 03:23:34 +04:00
EXPORT_SYMBOL ( acpi_os_map_generic_address ) ;
2010-10-22 00:23:59 +04:00
2011-11-08 03:23:34 +04:00
void acpi_os_unmap_generic_address ( struct acpi_generic_address * gas )
2010-10-22 00:23:59 +04:00
{
2011-11-08 03:23:27 +04:00
u64 addr ;
2011-02-09 01:37:53 +03:00
struct acpi_ioremap * map ;
2010-10-22 00:23:59 +04:00
2011-11-08 03:23:27 +04:00
if ( gas - > space_id ! = ACPI_ADR_SPACE_SYSTEM_MEMORY )
2010-10-22 00:23:59 +04:00
return ;
2011-11-08 03:23:27 +04:00
/* Handle possible alignment issues */
memcpy ( & addr , & gas - > address , sizeof ( addr ) ) ;
if ( ! addr | | ! gas - > bit_width )
2010-10-22 00:23:59 +04:00
return ;
2011-02-09 01:37:42 +03:00
mutex_lock ( & acpi_ioremap_lock ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
2011-11-08 03:23:27 +04:00
map = acpi_map_lookup ( addr , gas - > bit_width / 8 ) ;
2011-02-09 01:37:53 +03:00
if ( ! map ) {
mutex_unlock ( & acpi_ioremap_lock ) ;
return ;
}
2020-07-02 15:13:46 +03:00
acpi_os_drop_map_ref ( map ) ;
ACPI: OSL: Implement deferred unmapping of ACPI memory
The ACPI OS layer in Linux uses RCU to protect the walkers of the
list of ACPI memory mappings from seeing an inconsistent state
while it is being updated. Among other situations, that list can
be walked in (NMI and non-NMI) interrupt context, so using a
sleeping lock to protect it is not an option.
However, performance issues related to the RCU usage in there
appear, as described by Dan Williams:
"Recently a performance problem was reported for a process invoking
a non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
acpi_ex_write_with_update_rule
acpi_ex_field_datum_io
acpi_ex_access_region
acpi_ev_address_space_dispatch
acpi_ex_system_memory_space_handler
acpi_os_map_cleanup.part.14
_synchronize_rcu_expedited.constprop.89
schedule
The end result of frequent synchronize_rcu_expedited() invocation is
tiny sub-millisecond spurts of execution where the scheduler freely
migrates this apparently sleepy task. The overhead of frequent
scheduler invocation multiplies the execution time by a factor
of 2-3X."
The source of this is that acpi_ex_system_memory_space_handler()
unmaps the memory mapping currently cached by it at the access time
if that mapping doesn't cover the memory area being accessed.
Consequently, if there is a memory opregion with two fields
separated from each other by an unused chunk of address space that
is large enough for not being covered by a single mapping, and they
happen to be used in an alternating pattern, the unmapping will
occur on every acpi_ex_system_memory_space_handler() invocation for
that memory opregion and that will lead to significant overhead.
Moreover, acpi_ex_system_memory_space_handler() carries out the
memory unmapping with the namespace and interpreter mutexes held
which may lead to additional latency, because all of the tasks
wanting to acquire on of these mutexes need to wait for the
memory unmapping operation to complete.
To address that, rework acpi_os_unmap_memory() so that it does not
release the memory mapping covering the given address range right
away and instead make it queue up the mapping at hand for removal
via queue_rcu_work().
Reported-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Xiang Li <xiang.z.li@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-07-02 14:19:12 +03:00
2011-02-09 01:37:42 +03:00
mutex_unlock ( & acpi_ioremap_lock ) ;
2010-10-22 00:23:59 +04:00
}
2011-11-08 03:23:34 +04:00
EXPORT_SYMBOL ( acpi_os_unmap_generic_address ) ;
2010-10-22 00:23:59 +04:00
2005-04-17 02:20:36 +04:00
# ifdef ACPI_FUTURE_USAGE
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_get_physical_address ( void * virt , acpi_physical_address * phys )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
if ( ! phys | | ! virt )
2005-04-17 02:20:36 +04:00
return AE_BAD_PARAMETER ;
* phys = virt_to_phys ( virt ) ;
return AE_OK ;
}
# endif
2015-07-03 02:06:00 +03:00
# ifdef CONFIG_ACPI_REV_OVERRIDE_POSSIBLE
static bool acpi_rev_override ;
int __init acpi_rev_override_setup ( char * str )
{
acpi_rev_override = true ;
return 1 ;
}
__setup ( " acpi_rev_override " , acpi_rev_override_setup ) ;
# else
# define acpi_rev_override false
# endif
2005-04-17 02:20:36 +04:00
# define ACPI_MAX_OVERRIDE_LEN 100
static char acpi_os_name [ ACPI_MAX_OVERRIDE_LEN ] ;
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_predefined_override ( const struct acpi_predefined_names * init_val ,
2016-03-24 04:38:28 +03:00
acpi_string * new_val )
2005-04-17 02:20:36 +04:00
{
if ( ! init_val | | ! new_val )
return AE_BAD_PARAMETER ;
* new_val = NULL ;
2005-08-05 08:44:28 +04:00
if ( ! memcmp ( init_val - > name , " _OS_ " , 4 ) & & strlen ( acpi_os_name ) ) {
2005-04-17 02:20:36 +04:00
printk ( KERN_INFO PREFIX " Overriding _OS definition to '%s' \n " ,
2005-08-05 08:44:28 +04:00
acpi_os_name ) ;
2005-04-17 02:20:36 +04:00
* new_val = acpi_os_name ;
}
2015-07-03 02:06:00 +03:00
if ( ! memcmp ( init_val - > name , " _REV " , 4 ) & & acpi_rev_override ) {
printk ( KERN_INFO PREFIX " Overriding _REV return value to 5 \n " ) ;
* new_val = ( char * ) 5 ;
}
2005-04-17 02:20:36 +04:00
return AE_OK ;
}
IRQ: Maintain regs pointer globally rather than passing to IRQ handlers
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
2006-10-05 17:55:46 +04:00
static irqreturn_t acpi_irq ( int irq , void * dev_id )
2005-04-17 02:20:36 +04:00
{
2008-02-06 09:26:55 +03:00
u32 handled ;
handled = ( * acpi_irq_handler ) ( acpi_irq_context ) ;
if ( handled ) {
acpi_irq_handled + + ;
return IRQ_HANDLED ;
2009-04-21 08:35:47 +04:00
} else {
acpi_irq_not_handled + + ;
2008-02-06 09:26:55 +03:00
return IRQ_NONE ;
2009-04-21 08:35:47 +04:00
}
2005-04-17 02:20:36 +04:00
}
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_install_interrupt_handler ( u32 gsi , acpi_osd_handler handler ,
void * context )
2005-04-17 02:20:36 +04:00
{
unsigned int irq ;
2008-02-06 09:26:55 +03:00
acpi_irq_stats_init ( ) ;
2005-04-17 02:20:36 +04:00
/*
2011-02-09 01:48:16 +03:00
* ACPI interrupts different from the SCI in our copy of the FADT are
* not supported .
2005-04-17 02:20:36 +04:00
*/
2011-02-09 01:48:16 +03:00
if ( gsi ! = acpi_gbl_FADT . sci_interrupt )
return AE_BAD_PARAMETER ;
if ( acpi_irq_handler )
return AE_ALREADY_ACQUIRED ;
2005-04-17 02:20:36 +04:00
if ( acpi_gsi_to_irq ( gsi , & irq ) < 0 ) {
printk ( KERN_ERR PREFIX " SCI (ACPI GSI %d) not registered \n " ,
gsi ) ;
return AE_OK ;
}
acpi_irq_handler = handler ;
acpi_irq_context = context ;
2014-09-30 04:29:01 +04:00
if ( request_irq ( irq , acpi_irq , IRQF_SHARED , " acpi " , acpi_irq ) ) {
2005-04-17 02:20:36 +04:00
printk ( KERN_ERR PREFIX " SCI (IRQ%d) allocation failed \n " , irq ) ;
2011-02-09 01:48:16 +03:00
acpi_irq_handler = NULL ;
2005-04-17 02:20:36 +04:00
return AE_NOT_ACQUIRED ;
}
2015-10-24 20:02:19 +03:00
acpi_sci_irq = irq ;
2005-04-17 02:20:36 +04:00
return AE_OK ;
}
2015-10-24 20:02:19 +03:00
acpi_status acpi_os_remove_interrupt_handler ( u32 gsi , acpi_osd_handler handler )
2005-04-17 02:20:36 +04:00
{
2015-10-24 20:02:19 +03:00
if ( gsi ! = acpi_gbl_FADT . sci_interrupt | | ! acpi_sci_irq_valid ( ) )
2011-02-09 01:48:16 +03:00
return AE_BAD_PARAMETER ;
2015-10-24 20:02:19 +03:00
free_irq ( acpi_sci_irq , acpi_irq ) ;
2011-02-09 01:48:16 +03:00
acpi_irq_handler = NULL ;
2015-10-24 20:02:19 +03:00
acpi_sci_irq = INVALID_ACPI_IRQ ;
2005-04-17 02:20:36 +04:00
return AE_OK ;
}
/*
* Running in interpreter thread context , safe to sleep
*/
2010-01-28 05:53:19 +03:00
void acpi_os_sleep ( u64 ms )
2005-04-17 02:20:36 +04:00
{
2013-09-11 21:42:57 +04:00
msleep ( ms ) ;
2005-04-17 02:20:36 +04:00
}
2005-08-05 08:44:28 +04:00
void acpi_os_stall ( u32 us )
2005-04-17 02:20:36 +04:00
{
while ( us ) {
u32 delay = 1000 ;
if ( delay > us )
delay = us ;
udelay ( delay ) ;
touch_nmi_watchdog ( ) ;
us - = delay ;
}
}
2005-08-05 08:44:28 +04:00
2005-04-17 02:20:36 +04:00
/*
2018-10-17 23:24:56 +03:00
* Support ACPI 3.0 AML Timer operand . Returns a 64 - bit free - running ,
* monotonically increasing timer with 100 ns granularity . Do not use
* ktime_get ( ) to implement this function because this function may get
* called after timekeeping has been suspended . Note : calling this function
* after timekeeping has been suspended may lead to unexpected results
* because when timekeeping is suspended the jiffies counter is not
* incremented . See also timekeeping_suspend ( ) .
2005-04-17 02:20:36 +04:00
*/
2005-08-05 08:44:28 +04:00
u64 acpi_os_get_timer ( void )
2005-04-17 02:20:36 +04:00
{
2018-10-17 23:24:56 +03:00
return ( get_jiffies_64 ( ) - INITIAL_JIFFIES ) *
( ACPI_100NSEC_PER_SEC / HZ ) ;
2005-04-17 02:20:36 +04:00
}
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_read_port ( acpi_io_address port , u32 * value , u32 width )
2005-04-17 02:20:36 +04:00
{
u32 dummy ;
if ( ! value )
value = & dummy ;
2007-11-15 12:01:06 +03:00
* value = 0 ;
if ( width < = 8 ) {
2005-08-05 08:44:28 +04:00
* ( u8 * ) value = inb ( port ) ;
2007-11-15 12:01:06 +03:00
} else if ( width < = 16 ) {
2005-08-05 08:44:28 +04:00
* ( u16 * ) value = inw ( port ) ;
2007-11-15 12:01:06 +03:00
} else if ( width < = 32 ) {
2005-08-05 08:44:28 +04:00
* ( u32 * ) value = inl ( port ) ;
2007-11-15 12:01:06 +03:00
} else {
2005-04-17 02:20:36 +04:00
BUG ( ) ;
}
return AE_OK ;
}
2005-08-05 08:44:28 +04:00
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( acpi_os_read_port ) ;
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_write_port ( acpi_io_address port , u32 value , u32 width )
2005-04-17 02:20:36 +04:00
{
2007-11-15 12:01:06 +03:00
if ( width < = 8 ) {
2005-04-17 02:20:36 +04:00
outb ( value , port ) ;
2007-11-15 12:01:06 +03:00
} else if ( width < = 16 ) {
2005-04-17 02:20:36 +04:00
outw ( value , port ) ;
2007-11-15 12:01:06 +03:00
} else if ( width < = 32 ) {
2005-04-17 02:20:36 +04:00
outl ( value , port ) ;
2007-11-15 12:01:06 +03:00
} else {
2005-04-17 02:20:36 +04:00
BUG ( ) ;
}
return AE_OK ;
}
2005-08-05 08:44:28 +04:00
2005-04-17 02:20:36 +04:00
EXPORT_SYMBOL ( acpi_os_write_port ) ;
2017-10-06 02:24:03 +03:00
int acpi_os_read_iomem ( void __iomem * virt_addr , u64 * value , u32 width )
{
switch ( width ) {
case 8 :
* ( u8 * ) value = readb ( virt_addr ) ;
break ;
case 16 :
* ( u16 * ) value = readw ( virt_addr ) ;
break ;
case 32 :
* ( u32 * ) value = readl ( virt_addr ) ;
break ;
case 64 :
* ( u64 * ) value = readq ( virt_addr ) ;
break ;
default :
return - EINVAL ;
}
return 0 ;
}
2012-01-21 06:13:24 +04:00
acpi_status
2012-02-14 14:29:55 +04:00
acpi_os_read_memory ( acpi_physical_address phys_addr , u64 * value , u32 width )
2012-01-21 06:13:24 +04:00
{
void __iomem * virt_addr ;
unsigned int size = width / 8 ;
bool unmap = false ;
u64 dummy ;
2017-10-06 02:24:03 +03:00
int error ;
2012-01-21 06:13:24 +04:00
rcu_read_lock ( ) ;
virt_addr = acpi_map_vaddr_lookup ( phys_addr , size ) ;
if ( ! virt_addr ) {
rcu_read_unlock ( ) ;
virt_addr = acpi_os_ioremap ( phys_addr , size ) ;
if ( ! virt_addr )
return AE_BAD_ADDRESS ;
unmap = true ;
}
if ( ! value )
value = & dummy ;
2017-10-06 02:24:03 +03:00
error = acpi_os_read_iomem ( virt_addr , value , width ) ;
BUG_ON ( error ) ;
2012-01-21 06:13:24 +04:00
if ( unmap )
iounmap ( virt_addr ) ;
else
rcu_read_unlock ( ) ;
return AE_OK ;
}
acpi_status
2012-02-14 14:29:55 +04:00
acpi_os_write_memory ( acpi_physical_address phys_addr , u64 value , u32 width )
2012-01-21 06:13:24 +04:00
{
void __iomem * virt_addr ;
unsigned int size = width / 8 ;
bool unmap = false ;
rcu_read_lock ( ) ;
virt_addr = acpi_map_vaddr_lookup ( phys_addr , size ) ;
if ( ! virt_addr ) {
rcu_read_unlock ( ) ;
virt_addr = acpi_os_ioremap ( phys_addr , size ) ;
if ( ! virt_addr )
return AE_BAD_ADDRESS ;
unmap = true ;
}
switch ( width ) {
case 8 :
writeb ( value , virt_addr ) ;
break ;
case 16 :
writew ( value , virt_addr ) ;
break ;
case 32 :
writel ( value , virt_addr ) ;
break ;
case 64 :
2015-08-17 17:28:46 +03:00
writeq ( value , virt_addr ) ;
2012-01-21 06:13:24 +04:00
break ;
default :
BUG ( ) ;
}
if ( unmap )
iounmap ( virt_addr ) ;
else
rcu_read_unlock ( ) ;
return AE_OK ;
}
2018-12-20 01:46:55 +03:00
# ifdef CONFIG_PCI
2005-04-17 02:20:36 +04:00
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_read_pci_configuration ( struct acpi_pci_id * pci_id , u32 reg ,
2010-08-06 04:57:53 +04:00
u64 * value , u32 width )
2005-04-17 02:20:36 +04:00
{
int result , size ;
2010-08-06 04:57:53 +04:00
u32 value32 ;
2005-04-17 02:20:36 +04:00
if ( ! value )
return AE_BAD_PARAMETER ;
switch ( width ) {
case 8 :
size = 1 ;
break ;
case 16 :
size = 2 ;
break ;
case 32 :
size = 4 ;
break ;
default :
return AE_ERROR ;
}
2008-02-10 17:45:28 +03:00
result = raw_pci_read ( pci_id - > segment , pci_id - > bus ,
PCI_DEVFN ( pci_id - > device , pci_id - > function ) ,
2010-08-06 04:57:53 +04:00
reg , size , & value32 ) ;
* value = value32 ;
2005-04-17 02:20:36 +04:00
return ( result ? AE_ERROR : AE_OK ) ;
}
2005-08-05 08:44:28 +04:00
2005-04-17 02:20:36 +04:00
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_write_pci_configuration ( struct acpi_pci_id * pci_id , u32 reg ,
2010-01-28 05:53:19 +03:00
u64 value , u32 width )
2005-04-17 02:20:36 +04:00
{
int result , size ;
switch ( width ) {
case 8 :
size = 1 ;
break ;
case 16 :
size = 2 ;
break ;
case 32 :
size = 4 ;
break ;
default :
return AE_ERROR ;
}
2008-02-10 17:45:28 +03:00
result = raw_pci_write ( pci_id - > segment , pci_id - > bus ,
PCI_DEVFN ( pci_id - > device , pci_id - > function ) ,
reg , size , value ) ;
2005-04-17 02:20:36 +04:00
return ( result ? AE_ERROR : AE_OK ) ;
}
2018-12-20 01:46:55 +03:00
# endif
2005-04-17 02:20:36 +04:00
2006-11-22 17:55:48 +03:00
static void acpi_os_execute_deferred ( struct work_struct * work )
ACPI: created a dedicated workqueue for notify() execution
HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.
Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some variable
and lets the loop above break.
In the current ACPI implementation Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% cpu utilization by kacpid for several seconds
or more.
To prevent all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel stack
overflow.
First attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.
Second attempt was done by me, I created a new thread for each Notify
event. This worked OK on HP nx machines, but broke Linus' Compaq
n620c, by producing threads with a speed what they stopped the machine
completely. Thus this patch was reverted from 18-rc2 as I remember.
I re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).
Now you see last variant which adds yield() to every GPE execution.
http://bugzilla.kernel.org/show_bug.cgi?id=5534
http://bugzilla.kernel.org/show_bug.cgi?id=8385
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-05-10 07:31:03 +04:00
{
struct acpi_os_dpc * dpc = container_of ( work , struct acpi_os_dpc , work ) ;
2008-08-28 06:05:06 +04:00
dpc - > function ( dpc - > context ) ;
kfree ( dpc ) ;
}
2015-12-03 05:43:14 +03:00
# ifdef CONFIG_ACPI_DEBUGGER
static struct acpi_debugger acpi_debugger ;
static bool acpi_debugger_initialized ;
int acpi_register_debugger ( struct module * owner ,
const struct acpi_debugger_ops * ops )
{
int ret = 0 ;
mutex_lock ( & acpi_debugger . lock ) ;
if ( acpi_debugger . ops ) {
ret = - EBUSY ;
goto err_lock ;
}
acpi_debugger . owner = owner ;
acpi_debugger . ops = ops ;
err_lock :
mutex_unlock ( & acpi_debugger . lock ) ;
return ret ;
}
EXPORT_SYMBOL ( acpi_register_debugger ) ;
void acpi_unregister_debugger ( const struct acpi_debugger_ops * ops )
{
mutex_lock ( & acpi_debugger . lock ) ;
if ( ops = = acpi_debugger . ops ) {
acpi_debugger . ops = NULL ;
acpi_debugger . owner = NULL ;
}
mutex_unlock ( & acpi_debugger . lock ) ;
}
EXPORT_SYMBOL ( acpi_unregister_debugger ) ;
int acpi_debugger_create_thread ( acpi_osd_exec_callback function , void * context )
{
int ret ;
int ( * func ) ( acpi_osd_exec_callback , void * ) ;
struct module * owner ;
if ( ! acpi_debugger_initialized )
return - ENODEV ;
mutex_lock ( & acpi_debugger . lock ) ;
if ( ! acpi_debugger . ops ) {
ret = - ENODEV ;
goto err_lock ;
}
if ( ! try_module_get ( acpi_debugger . owner ) ) {
ret = - ENODEV ;
goto err_lock ;
}
func = acpi_debugger . ops - > create_thread ;
owner = acpi_debugger . owner ;
mutex_unlock ( & acpi_debugger . lock ) ;
ret = func ( function , context ) ;
mutex_lock ( & acpi_debugger . lock ) ;
module_put ( owner ) ;
err_lock :
mutex_unlock ( & acpi_debugger . lock ) ;
return ret ;
}
ssize_t acpi_debugger_write_log ( const char * msg )
{
ssize_t ret ;
ssize_t ( * func ) ( const char * ) ;
struct module * owner ;
if ( ! acpi_debugger_initialized )
return - ENODEV ;
mutex_lock ( & acpi_debugger . lock ) ;
if ( ! acpi_debugger . ops ) {
ret = - ENODEV ;
goto err_lock ;
}
if ( ! try_module_get ( acpi_debugger . owner ) ) {
ret = - ENODEV ;
goto err_lock ;
}
func = acpi_debugger . ops - > write_log ;
owner = acpi_debugger . owner ;
mutex_unlock ( & acpi_debugger . lock ) ;
ret = func ( msg ) ;
mutex_lock ( & acpi_debugger . lock ) ;
module_put ( owner ) ;
err_lock :
mutex_unlock ( & acpi_debugger . lock ) ;
return ret ;
}
ssize_t acpi_debugger_read_cmd ( char * buffer , size_t buffer_length )
{
ssize_t ret ;
ssize_t ( * func ) ( char * , size_t ) ;
struct module * owner ;
if ( ! acpi_debugger_initialized )
return - ENODEV ;
mutex_lock ( & acpi_debugger . lock ) ;
if ( ! acpi_debugger . ops ) {
ret = - ENODEV ;
goto err_lock ;
}
if ( ! try_module_get ( acpi_debugger . owner ) ) {
ret = - ENODEV ;
goto err_lock ;
}
func = acpi_debugger . ops - > read_cmd ;
owner = acpi_debugger . owner ;
mutex_unlock ( & acpi_debugger . lock ) ;
ret = func ( buffer , buffer_length ) ;
mutex_lock ( & acpi_debugger . lock ) ;
module_put ( owner ) ;
err_lock :
mutex_unlock ( & acpi_debugger . lock ) ;
return ret ;
}
int acpi_debugger_wait_command_ready ( void )
{
int ret ;
int ( * func ) ( bool , char * , size_t ) ;
struct module * owner ;
if ( ! acpi_debugger_initialized )
return - ENODEV ;
mutex_lock ( & acpi_debugger . lock ) ;
if ( ! acpi_debugger . ops ) {
ret = - ENODEV ;
goto err_lock ;
}
if ( ! try_module_get ( acpi_debugger . owner ) ) {
ret = - ENODEV ;
goto err_lock ;
}
func = acpi_debugger . ops - > wait_command_ready ;
owner = acpi_debugger . owner ;
mutex_unlock ( & acpi_debugger . lock ) ;
ret = func ( acpi_gbl_method_executing ,
acpi_gbl_db_line_buf , ACPI_DB_LINE_BUFFER_SIZE ) ;
mutex_lock ( & acpi_debugger . lock ) ;
module_put ( owner ) ;
err_lock :
mutex_unlock ( & acpi_debugger . lock ) ;
return ret ;
}
int acpi_debugger_notify_command_complete ( void )
{
int ret ;
int ( * func ) ( void ) ;
struct module * owner ;
if ( ! acpi_debugger_initialized )
return - ENODEV ;
mutex_lock ( & acpi_debugger . lock ) ;
if ( ! acpi_debugger . ops ) {
ret = - ENODEV ;
goto err_lock ;
}
if ( ! try_module_get ( acpi_debugger . owner ) ) {
ret = - ENODEV ;
goto err_lock ;
}
func = acpi_debugger . ops - > notify_command_complete ;
owner = acpi_debugger . owner ;
mutex_unlock ( & acpi_debugger . lock ) ;
ret = func ( ) ;
mutex_lock ( & acpi_debugger . lock ) ;
module_put ( owner ) ;
err_lock :
mutex_unlock ( & acpi_debugger . lock ) ;
return ret ;
}
int __init acpi_debugger_init ( void )
{
mutex_init ( & acpi_debugger . lock ) ;
acpi_debugger_initialized = true ;
return 0 ;
}
# endif
2006-05-05 11:23:00 +04:00
/*******************************************************************************
*
* FUNCTION : acpi_os_execute
*
* PARAMETERS : Type - Type of the callback
* Function - Function to be executed
* Context - Function parameters
*
* RETURN : Status
*
* DESCRIPTION : Depending on type , either queues function for deferred execution or
* immediately executes function on a separate thread .
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
acpi_status acpi_os_execute ( acpi_execute_type type ,
acpi_osd_exec_callback function , void * context )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
acpi_status status = AE_OK ;
struct acpi_os_dpc * dpc ;
2007-11-13 13:05:45 +03:00
struct workqueue_struct * queue ;
2008-08-28 06:05:06 +04:00
int ret ;
2006-07-13 06:46:42 +04:00
ACPI_DEBUG_PRINT ( ( ACPI_DB_EXEC ,
" Scheduling function [%p(%p)] for deferred execution. \n " ,
function , context ) ) ;
2005-04-17 02:20:36 +04:00
2015-12-03 05:43:00 +03:00
if ( type = = OSL_DEBUGGER_MAIN_THREAD ) {
2015-12-03 05:43:14 +03:00
ret = acpi_debugger_create_thread ( function , context ) ;
2015-12-03 05:43:00 +03:00
if ( ret ) {
pr_err ( " Call to kthread_create() failed. \n " ) ;
status = AE_ERROR ;
}
goto out_thread ;
}
2005-04-17 02:20:36 +04:00
/*
* Allocate / initialize DPC structure . Note that this memory will be
2006-11-22 17:55:48 +03:00
* freed by the callee . The kernel handles the work_struct list in a
2005-04-17 02:20:36 +04:00
* way that allows us to also free its memory inside the callee .
* Because we may want to schedule several tasks with different
* parameters we can ' t use the approach some kernel code uses of
2006-11-22 17:55:48 +03:00
* having a static work_struct .
2005-04-17 02:20:36 +04:00
*/
2006-07-13 06:46:42 +04:00
2012-11-02 16:09:08 +04:00
dpc = kzalloc ( sizeof ( struct acpi_os_dpc ) , GFP_ATOMIC ) ;
2005-04-17 02:20:36 +04:00
if ( ! dpc )
2008-12-31 04:23:57 +03:00
return AE_NO_MEMORY ;
2006-11-18 06:31:09 +03:00
2005-04-17 02:20:36 +04:00
dpc - > function = function ;
dpc - > context = context ;
2006-11-18 06:31:09 +03:00
2009-06-23 06:20:29 +04:00
/*
2012-11-02 16:09:08 +04:00
* To prevent lockdep from complaining unnecessarily , make sure that
* there is a different static lockdep key for each workqueue by using
* INIT_WORK ( ) for each of them separately .
2009-06-23 06:20:29 +04:00
*/
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
if ( type = = OSL_NOTIFY_HANDLER ) {
2012-11-02 16:09:08 +04:00
queue = kacpi_notify_wq ;
2010-03-22 10:48:54 +03:00
INIT_WORK ( & dpc - > work , acpi_os_execute_deferred ) ;
2015-12-03 05:43:00 +03:00
} else if ( type = = OSL_GPE_HANDLER ) {
2012-11-02 16:09:08 +04:00
queue = kacpid_wq ;
2010-03-22 10:48:54 +03:00
INIT_WORK ( & dpc - > work , acpi_os_execute_deferred ) ;
2015-12-03 05:43:00 +03:00
} else {
pr_err ( " Unsupported os_execute type %d. \n " , type ) ;
status = AE_ERROR ;
2012-11-02 16:09:08 +04:00
}
2010-03-22 10:48:54 +03:00
2015-12-03 05:43:00 +03:00
if ( ACPI_FAILURE ( status ) )
goto err_workqueue ;
2010-06-29 12:07:09 +04:00
/*
* 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 always
* queueing on CPU 0.
*/
ret = queue_work_on ( 0 , queue , & dpc - > work ) ;
2008-08-28 06:05:06 +04:00
if ( ! ret ) {
2008-09-28 10:51:56 +04:00
printk ( KERN_ERR PREFIX
" Call to queue_work() failed. \n " ) ;
2007-11-13 13:05:45 +03:00
status = AE_ERROR ;
2005-04-17 02:20:36 +04:00
}
2015-12-03 05:43:00 +03:00
err_workqueue :
if ( ACPI_FAILURE ( status ) )
kfree ( dpc ) ;
out_thread :
2008-12-31 04:23:57 +03:00
return status ;
2005-04-17 02:20:36 +04:00
}
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
EXPORT_SYMBOL ( acpi_os_execute ) ;
2005-08-05 08:44:28 +04:00
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
void acpi_os_wait_events_complete ( void )
2008-08-28 06:05:06 +04:00
{
ACPI / OSL: Add IRQ handler flushing support in the OSL.
It is possible that a GPE handler or a fixed event handler still accessed
after removing the handlers by invoking acpi_remove_gpe_handler() or
acpi_remove_fixed_event_handler(), this possibility can crash OPSM after a
module removal. In the Linux kernel, though all other GPE drivers are not
modules, since the IPMI_SI (ipmi_si_intf.c) can be compiled as a module, we
still need to consider a solution for this issue when the driver switches
to ACPI_GPE_RAW_HANDLER mode in order to invoke GPE APIs.
ACPICA expects acpi_os_wait_events_complete() to be invoked after GPE
disabling so that OSPM can ensure all running GPE handlers have exitted.
But currently acpi_os_wait_events_complete() can only flush _Lxx/_Exx
evaluation work queue and this philosophy cannot work for drivers that have
installed a dedicated GPE handler.
The only way to protect a callback is to perform some state holders
(reference count, state machine) before invoking the callback. Then this
issue can only be fixed by the following means:
1. Flush GPE in ACPICA before invoking the GPE handler. But currently,
there is no such implementation in acpi_ev_gpe_dispatch().
2. Flush GPE in ACPICA OSL before invoking the SCI handler. But currently,
there is no such implementation in acpi_irq().
3. Flush IRQ in OSPM IRQ layer before invoking the IRQ handler. In Linus
kernel, this can be done by synchronize_irq().
4. Flush scheduling in OSPM vector entry layer before invoking the vector.
In Linux, this can be done by synchronize_sched().
Since ACPICA expects the GPE handlers to be flushed by the ACPICA OSL or
the GPE drivers. If it is implemented by the GPE driver, we should see
synchronize_irq()/synchronize_sched() invoked in such drivers. If it is
implemented by the ACPICA OSL, ACPICA currently provides
acpi_os_wait_events_complete() hook to achieve this. After the following
commit:
Commit: 69c841b6dd8313c9a673246cc0e2535174272cab
Author: Lv Zheng <lv.zheng@intel.com>
Subject: ACPICA: Update use of acpi_os_wait_events_complete interface.
The OSL acpi_os_wait_events_complete() is invoked after a GPE handler is
removed from acpi_remove_gpe_handler() or a fixed event handler is removed
from acpi_remove_fixed_event_handler(). Thus it is possible to implement
GPE handler flushing using this ACPICA OSL now. So the solution 1 is
currently not taken into account.
By examining the IPMI_SI driver, we noticed that the IPMI_SI driver:
1. Uses free_irq() to flush non GPE based IRQ handlers, in free_irq(),
synchronize_irq() is invoked, and
2. Uses acpi_remove_gpe_handler() to flush GPE based IRQ handlers, for such
IRQ handlers, there is no synchronize_irq() invoked.
Since there isn't synchronize_sched() implemented for this driver, from the
driver's perspective, acpi_remove_gpe_handler() should have properly
flushed the GPE handlers for it. Since the driver doesn't invoke
synchronize_irq(), the solution 3 is not what the drivers expect.
This patch implements solution 2. But since given the fact that the GPE is
managed inside of ACPICA, and implementing the GPE flushing requires to
implement the whole GPE management code again in the OSL, instead of
flushing GPE, this patch flushes IRQ in acpi_os_wait_events_complete(). The
flushing could last longer than expected as though the target GPE/fixed
event that is removed can be fastly flushed, other GPEs/fix events can still
be issued during the flushing period.
This patch fixes this issue by invoking synchronize_hardirq() in
acpi_os_wait_events_complete(). The reason why we don't invoke
synchronize_irq() is: currently ACPICA is not threaded IRQ capable and the
only difference between synchronize_irq() and synchronize_hardirq() is
synchronize_irq() also flushes threaded IRQ handlers. Thus using
synchronize_hardirq() can help to reduce the overall synchronization time
for the current ACPICA implementation.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: linux-acpi@vger.kernel.org
Cc: devel@acpica.org
Cc: openipmi-developer@lists.sourceforge.net
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-05 10:06:13 +03:00
/*
* Make sure the GPE handler or the fixed event handler is not used
* on another CPU after removal .
*/
2015-10-24 20:02:36 +03:00
if ( acpi_sci_irq_valid ( ) )
synchronize_hardirq ( acpi_sci_irq ) ;
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
flush_workqueue ( kacpid_wq ) ;
flush_workqueue ( kacpi_notify_wq ) ;
2008-08-28 06:05:06 +04:00
}
2018-10-01 05:53:13 +03:00
EXPORT_SYMBOL ( acpi_os_wait_events_complete ) ;
2005-04-17 02:20:36 +04:00
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
struct acpi_hp_work {
struct work_struct work ;
2014-03-03 03:40:38 +04:00
struct acpi_device * adev ;
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
u32 src ;
} ;
static void acpi_hotplug_work_fn ( struct work_struct * work )
2008-08-28 06:05:06 +04:00
{
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
struct acpi_hp_work * hpw = container_of ( work , struct acpi_hp_work , work ) ;
acpi_os_wait_events_complete ( ) ;
2014-03-03 03:40:38 +04:00
acpi_device_hotplug ( hpw - > adev , hpw - > src ) ;
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
kfree ( hpw ) ;
2008-08-28 06:05:06 +04:00
}
2014-03-03 03:40:38 +04:00
acpi_status acpi_hotplug_schedule ( struct acpi_device * adev , u32 src )
2005-04-17 02:20:36 +04:00
{
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
struct acpi_hp_work * hpw ;
ACPI_DEBUG_PRINT ( ( ACPI_DB_EXEC ,
2014-03-03 03:40:38 +04:00
" Scheduling hotplug event (%p, %u) for deferred execution. \n " ,
adev , src ) ) ;
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
hpw = kmalloc ( sizeof ( * hpw ) , GFP_KERNEL ) ;
if ( ! hpw )
return AE_NO_MEMORY ;
INIT_WORK ( & hpw - > work , acpi_hotplug_work_fn ) ;
2014-03-03 03:40:38 +04:00
hpw - > adev = adev ;
ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines
There are two different interfaces for queuing up work items on the
ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
bridge hotplug code and acpi_os_hotplug_execute() used by the common
ACPI hotplug code and docking stations. They both are somewhat
cumbersome to use and work slightly differently.
The users of alloc_acpi_hp_work() have to submit a work function that
will extract the necessary data items from a struct acpi_hp_work
object allocated by alloc_acpi_hp_work() and then will free that
object, while it would be more straightforward to simply use a work
function with one more argument and let the interface take care of
the execution details.
The users of acpi_os_hotplug_execute() also have to deal with the
fact that it takes only one argument in addition to the work function
pointer, although acpi_os_execute_deferred() actually takes care of
the allocation and freeing of memory, so it would have been able to
pass more arguments to the work function if it hadn't been
constrained by the connection with acpi_os_execute().
Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
allocations, which is correct, because hotplug work items are
always queued up from process context, acpi_os_hotplug_execute()
uses GFP_ATOMIC, as that is needed by acpi_os_execute(). Also,
acpi_os_execute_deferred() queued up by it waits for the ACPI event
workqueues to flush before executing the work function, whereas
alloc_acpi_hp_work() can't do anything similar. That leads to
somewhat arbitrary differences in behavior between various ACPI
hotplug code paths and has to be straightened up.
For this reason, replace both alloc_acpi_hp_work() and
acpi_os_hotplug_execute() with a single interface,
acpi_hotplug_execute(), combining their behavior and being more
friendly to its users than any of the two.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2013-11-07 04:45:40 +04:00
hpw - > src = src ;
/*
* We can ' t run hotplug code in kacpid_wq / kacpid_notify_wq etc . , because
* the hotplug code may call driver . remove ( ) functions , which may
* invoke flush_scheduled_work ( ) / acpi_os_wait_events_complete ( ) to flush
* these workqueues .
*/
if ( ! queue_work ( kacpi_hotplug_wq , & hpw - > work ) ) {
kfree ( hpw ) ;
return AE_ERROR ;
}
return AE_OK ;
2005-04-17 02:20:36 +04:00
}
2005-08-05 08:44:28 +04:00
2013-11-23 00:52:12 +04:00
bool acpi_queue_hotplug_work ( struct work_struct * work )
{
return queue_work ( kacpi_hotplug_wq , work ) ;
}
2005-04-17 02:20:36 +04:00
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_create_semaphore ( u32 max_units , u32 initial_units , acpi_handle * handle )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
struct semaphore * sem = NULL ;
2005-04-17 02:20:36 +04:00
2014-03-20 11:35:56 +04:00
sem = acpi_os_allocate_zeroed ( sizeof ( struct semaphore ) ) ;
2005-04-17 02:20:36 +04:00
if ( ! sem )
2006-06-27 08:41:40 +04:00
return AE_NO_MEMORY ;
2005-04-17 02:20:36 +04:00
sema_init ( sem , initial_units ) ;
2005-08-05 08:44:28 +04:00
* handle = ( acpi_handle * ) sem ;
2005-04-17 02:20:36 +04:00
2005-08-05 08:44:28 +04:00
ACPI_DEBUG_PRINT ( ( ACPI_DB_MUTEX , " Creating semaphore[%p|%d]. \n " ,
* handle , initial_units ) ) ;
2005-04-17 02:20:36 +04:00
2006-06-27 08:41:40 +04:00
return AE_OK ;
2005-04-17 02:20:36 +04:00
}
/*
* TODO : A better way to delete semaphores ? Linux doesn ' t have a
* ' delete_semaphore ( ) ' function - - may result in an invalid
* pointer dereference for non - synchronized consumers . Should
* we at least check for blocked threads and signal / cancel them ?
*/
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_delete_semaphore ( acpi_handle handle )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
struct semaphore * sem = ( struct semaphore * ) handle ;
2005-04-17 02:20:36 +04:00
if ( ! sem )
2006-06-27 08:41:40 +04:00
return AE_BAD_PARAMETER ;
2005-04-17 02:20:36 +04:00
2005-08-05 08:44:28 +04:00
ACPI_DEBUG_PRINT ( ( ACPI_DB_MUTEX , " Deleting semaphore[%p]. \n " , handle ) ) ;
2005-04-17 02:20:36 +04:00
2008-03-14 20:43:13 +03:00
BUG_ON ( ! list_empty ( & sem - > wait_list ) ) ;
2006-06-30 11:19:10 +04:00
kfree ( sem ) ;
2005-08-05 08:44:28 +04:00
sem = NULL ;
2005-04-17 02:20:36 +04:00
2006-06-27 08:41:40 +04:00
return AE_OK ;
2005-04-17 02:20:36 +04:00
}
/*
* TODO : Support for units > 1 ?
*/
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_wait_semaphore ( acpi_handle handle , u32 units , u16 timeout )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
acpi_status status = AE_OK ;
struct semaphore * sem = ( struct semaphore * ) handle ;
2008-03-14 20:43:13 +03:00
long jiffies ;
2005-08-05 08:44:28 +04:00
int ret = 0 ;
2005-04-17 02:20:36 +04:00
2015-08-05 11:23:51 +03:00
if ( ! acpi_os_initialized )
return AE_OK ;
2005-04-17 02:20:36 +04:00
if ( ! sem | | ( units < 1 ) )
2006-06-27 08:41:40 +04:00
return AE_BAD_PARAMETER ;
2005-04-17 02:20:36 +04:00
if ( units > 1 )
2006-06-27 08:41:40 +04:00
return AE_SUPPORT ;
2005-04-17 02:20:36 +04:00
2005-08-05 08:44:28 +04:00
ACPI_DEBUG_PRINT ( ( ACPI_DB_MUTEX , " Waiting for semaphore[%p|%d|%d] \n " ,
handle , units , timeout ) ) ;
2005-04-17 02:20:36 +04:00
2008-03-14 20:43:13 +03:00
if ( timeout = = ACPI_WAIT_FOREVER )
jiffies = MAX_SCHEDULE_TIMEOUT ;
else
jiffies = msecs_to_jiffies ( timeout ) ;
2013-12-04 23:59:11 +04:00
2008-03-14 20:43:13 +03:00
ret = down_timeout ( sem , jiffies ) ;
if ( ret )
status = AE_TIME ;
2005-04-17 02:20:36 +04:00
if ( ACPI_FAILURE ( status ) ) {
2006-04-27 13:25:00 +04:00
ACPI_DEBUG_PRINT ( ( ACPI_DB_MUTEX ,
2006-06-27 07:58:43 +04:00
" Failed to acquire semaphore[%p|%d|%d], %s " ,
2005-08-05 08:44:28 +04:00
handle , units , timeout ,
acpi_format_exception ( status ) ) ) ;
} else {
ACPI_DEBUG_PRINT ( ( ACPI_DB_MUTEX ,
2006-06-27 07:58:43 +04:00
" Acquired semaphore[%p|%d|%d] " , handle ,
2005-08-05 08:44:28 +04:00
units , timeout ) ) ;
2005-04-17 02:20:36 +04:00
}
2006-06-27 08:41:40 +04:00
return status ;
2005-04-17 02:20:36 +04:00
}
/*
* TODO : Support for units > 1 ?
*/
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_signal_semaphore ( acpi_handle handle , u32 units )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
struct semaphore * sem = ( struct semaphore * ) handle ;
2005-04-17 02:20:36 +04:00
2015-08-05 11:23:51 +03:00
if ( ! acpi_os_initialized )
return AE_OK ;
2005-04-17 02:20:36 +04:00
if ( ! sem | | ( units < 1 ) )
2006-06-27 08:41:40 +04:00
return AE_BAD_PARAMETER ;
2005-04-17 02:20:36 +04:00
if ( units > 1 )
2006-06-27 08:41:40 +04:00
return AE_SUPPORT ;
2005-04-17 02:20:36 +04:00
2005-08-05 08:44:28 +04:00
ACPI_DEBUG_PRINT ( ( ACPI_DB_MUTEX , " Signaling semaphore[%p|%d] \n " , handle ,
units ) ) ;
2005-04-17 02:20:36 +04:00
up ( sem ) ;
2006-06-27 08:41:40 +04:00
return AE_OK ;
2005-04-17 02:20:36 +04:00
}
2005-08-05 08:44:28 +04:00
2015-10-19 05:25:56 +03:00
acpi_status acpi_os_get_line ( char * buffer , u32 buffer_length , u32 * bytes_read )
2005-04-17 02:20:36 +04:00
{
# ifdef ENABLE_DEBUGGER
if ( acpi_in_debugger ) {
u32 chars ;
2015-10-19 05:25:56 +03:00
kdb_read ( buffer , buffer_length ) ;
2005-04-17 02:20:36 +04:00
/* remove the CR kdb includes */
chars = strlen ( buffer ) - 1 ;
buffer [ chars ] = ' \0 ' ;
}
2015-12-03 05:43:00 +03:00
# else
int ret ;
2015-12-03 05:43:14 +03:00
ret = acpi_debugger_read_cmd ( buffer , buffer_length ) ;
2015-12-03 05:43:00 +03:00
if ( ret < 0 )
return AE_ERROR ;
if ( bytes_read )
* bytes_read = ret ;
2005-04-17 02:20:36 +04:00
# endif
2015-10-19 05:25:56 +03:00
return AE_OK ;
2005-04-17 02:20:36 +04:00
}
2015-12-03 05:43:14 +03:00
EXPORT_SYMBOL ( acpi_os_get_line ) ;
2005-04-17 02:20:36 +04:00
2015-12-03 05:43:00 +03:00
acpi_status acpi_os_wait_command_ready ( void )
{
int ret ;
2015-12-03 05:43:14 +03:00
ret = acpi_debugger_wait_command_ready ( ) ;
2015-12-03 05:43:00 +03:00
if ( ret < 0 )
return AE_ERROR ;
return AE_OK ;
}
acpi_status acpi_os_notify_command_complete ( void )
{
int ret ;
2015-12-03 05:43:14 +03:00
ret = acpi_debugger_notify_command_complete ( ) ;
2015-12-03 05:43:00 +03:00
if ( ret < 0 )
return AE_ERROR ;
return AE_OK ;
}
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_signal ( u32 function , void * info )
2005-04-17 02:20:36 +04:00
{
2005-08-05 08:44:28 +04:00
switch ( function ) {
2005-04-17 02:20:36 +04:00
case ACPI_SIGNAL_FATAL :
printk ( KERN_ERR PREFIX " Fatal opcode executed \n " ) ;
break ;
case ACPI_SIGNAL_BREAKPOINT :
/*
* AML Breakpoint
* ACPI spec . says to treat it as a NOP unless
* you are debugging . So if / when we integrate
* AML debugger into the kernel debugger its
* hook will go here . But until then it is
* not useful to print anything on breakpoints .
*/
break ;
default :
break ;
}
return AE_OK ;
}
2005-08-05 08:44:28 +04:00
static int __init acpi_os_name_setup ( char * str )
2005-04-17 02:20:36 +04:00
{
char * p = acpi_os_name ;
2005-08-05 08:44:28 +04:00
int count = ACPI_MAX_OVERRIDE_LEN - 1 ;
2005-04-17 02:20:36 +04:00
if ( ! str | | ! * str )
return 0 ;
2013-10-18 13:01:43 +04:00
for ( ; count - - & & * str ; str + + ) {
2005-04-17 02:20:36 +04:00
if ( isalnum ( * str ) | | * str = = ' ' | | * str = = ' : ' )
* p + + = * str ;
else if ( * str = = ' \' ' | | * str = = ' " ' )
continue ;
else
break ;
}
* p = 0 ;
return 1 ;
2005-08-05 08:44:28 +04:00
2005-04-17 02:20:36 +04:00
}
__setup ( " acpi_os_name= " , acpi_os_name_setup ) ;
2014-03-24 10:49:00 +04:00
/*
2014-03-24 10:49:22 +04:00
* Disable the auto - serialization of named objects creation methods .
2014-03-24 10:49:00 +04:00
*
2014-03-24 10:49:22 +04:00
* This feature is enabled by default . It marks the AML control methods
2014-03-24 10:49:00 +04:00
* that contain the opcodes to create named objects as " Serialized " .
*/
2014-03-24 10:49:22 +04:00
static int __init acpi_no_auto_serialize_setup ( char * str )
2005-04-17 02:20:36 +04:00
{
2014-03-24 10:49:22 +04:00
acpi_gbl_auto_serialize_methods = FALSE ;
pr_info ( " ACPI: auto-serialization disabled \n " ) ;
2005-04-17 02:20:36 +04:00
return 1 ;
}
2014-03-24 10:49:22 +04:00
__setup ( " acpi_no_auto_serialize " , acpi_no_auto_serialize_setup ) ;
2005-04-17 02:20:36 +04:00
2008-02-05 10:31:22 +03:00
/* Check of resource interference between native drivers and ACPI
* OperationRegions ( SystemIO and System Memory only ) .
* IO ports and memory declared in ACPI might be used by the ACPI subsystem
* in arbitrary AML code and can interfere with legacy drivers .
* acpi_enforce_resources = can be set to :
*
2009-03-30 02:01:27 +04:00
* - strict ( default ) ( 2 )
2008-02-05 10:31:22 +03:00
* - > further driver trying to access the resources will not load
2009-03-30 02:01:27 +04:00
* - lax ( 1 )
2008-02-05 10:31:22 +03:00
* - > further driver trying to access the resources will load , but you
* get a system message that something might go wrong . . .
*
* - no ( 0 )
* - > ACPI Operation Region resources will not be registered
*
*/
# define ENFORCE_RESOURCES_STRICT 2
# define ENFORCE_RESOURCES_LAX 1
# define ENFORCE_RESOURCES_NO 0
2009-03-30 02:01:27 +04:00
static unsigned int acpi_enforce_resources = ENFORCE_RESOURCES_STRICT ;
2008-02-05 10:31:22 +03:00
static int __init acpi_enforce_resources_setup ( char * str )
{
if ( str = = NULL | | * str = = ' \0 ' )
return 0 ;
if ( ! strcmp ( " strict " , str ) )
acpi_enforce_resources = ENFORCE_RESOURCES_STRICT ;
else if ( ! strcmp ( " lax " , str ) )
acpi_enforce_resources = ENFORCE_RESOURCES_LAX ;
else if ( ! strcmp ( " no " , str ) )
acpi_enforce_resources = ENFORCE_RESOURCES_NO ;
return 1 ;
}
__setup ( " acpi_enforce_resources= " , acpi_enforce_resources_setup ) ;
/* Check for resource conflicts between ACPI OperationRegions and native
* drivers */
2009-11-11 17:22:15 +03:00
int acpi_check_resource_conflict ( const struct resource * res )
2008-02-05 10:31:22 +03:00
{
2012-01-12 09:10:32 +04:00
acpi_adr_space_type space_id ;
2008-02-05 10:31:22 +03:00
if ( acpi_enforce_resources = = ENFORCE_RESOURCES_NO )
return 0 ;
2012-01-12 09:10:32 +04:00
if ( res - > flags & IORESOURCE_IO )
space_id = ACPI_ADR_SPACE_SYSTEM_IO ;
2021-02-09 17:59:04 +03:00
else if ( res - > flags & IORESOURCE_MEM )
2012-01-12 09:10:32 +04:00
space_id = ACPI_ADR_SPACE_SYSTEM_MEMORY ;
2021-02-09 17:59:04 +03:00
else
return 0 ;
if ( ! acpi_check_address_range ( space_id , res - > start , resource_size ( res ) , 1 ) )
return 0 ;
pr_info ( " Resource conflict; ACPI support missing from driver? \n " ) ;
if ( acpi_enforce_resources = = ENFORCE_RESOURCES_STRICT )
return - EBUSY ;
if ( acpi_enforce_resources = = ENFORCE_RESOURCES_LAX )
pr_notice ( " Resource conflict: System may be unstable or behave erratically \n " ) ;
2008-02-05 10:31:22 +03:00
return 0 ;
}
2008-02-05 10:31:23 +03:00
EXPORT_SYMBOL ( acpi_check_resource_conflict ) ;
2008-02-05 10:31:22 +03:00
int acpi_check_region ( resource_size_t start , resource_size_t n ,
const char * name )
{
struct resource res = {
. start = start ,
. end = start + n - 1 ,
. name = name ,
. flags = IORESOURCE_IO ,
} ;
return acpi_check_resource_conflict ( & res ) ;
}
EXPORT_SYMBOL ( acpi_check_region ) ;
2018-06-21 16:43:17 +03:00
static acpi_status acpi_deactivate_mem_region ( acpi_handle handle , u32 level ,
void * _res , void * * return_value )
{
struct acpi_mem_space_context * * mem_ctx ;
union acpi_operand_object * handler_obj ;
union acpi_operand_object * region_obj2 ;
union acpi_operand_object * region_obj ;
struct resource * res = _res ;
acpi_status status ;
region_obj = acpi_ns_get_attached_object ( handle ) ;
if ( ! region_obj )
return AE_OK ;
handler_obj = region_obj - > region . handler ;
if ( ! handler_obj )
return AE_OK ;
if ( region_obj - > region . space_id ! = ACPI_ADR_SPACE_SYSTEM_MEMORY )
return AE_OK ;
if ( ! ( region_obj - > region . flags & AOPOBJ_SETUP_COMPLETE ) )
return AE_OK ;
region_obj2 = acpi_ns_get_secondary_object ( region_obj ) ;
if ( ! region_obj2 )
return AE_OK ;
mem_ctx = ( void * ) & region_obj2 - > extra . region_context ;
if ( ! ( mem_ctx [ 0 ] - > address > = res - > start & &
mem_ctx [ 0 ] - > address < res - > end ) )
return AE_OK ;
status = handler_obj - > address_space . setup ( region_obj ,
ACPI_REGION_DEACTIVATE ,
NULL , ( void * * ) mem_ctx ) ;
if ( ACPI_SUCCESS ( status ) )
region_obj - > region . flags & = ~ ( AOPOBJ_SETUP_COMPLETE ) ;
return status ;
}
/**
* acpi_release_memory - Release any mappings done to a memory region
* @ handle : Handle to namespace node
* @ res : Memory resource
* @ level : A level that terminates the search
*
* Walks through @ handle and unmaps all SystemMemory Operation Regions that
* overlap with @ res and that have already been activated ( mapped ) .
*
* This is a helper that allows drivers to place special requirements on memory
* region that may overlap with operation regions , primarily allowing them to
* safely map the region as non - cached memory .
*
* The unmapped Operation Regions will be automatically remapped next time they
* are called , so the drivers do not need to do anything else .
*/
acpi_status acpi_release_memory ( acpi_handle handle , struct resource * res ,
u32 level )
{
2020-08-21 20:42:55 +03:00
acpi_status status ;
2018-06-21 16:43:17 +03:00
if ( ! ( res - > flags & IORESOURCE_MEM ) )
return AE_TYPE ;
2020-08-21 20:42:55 +03:00
status = acpi_walk_namespace ( ACPI_TYPE_REGION , handle , level ,
acpi_deactivate_mem_region , NULL ,
res , NULL ) ;
if ( ACPI_FAILURE ( status ) )
return status ;
/*
* Wait for all of the mappings queued up for removal by
* acpi_deactivate_mem_region ( ) to actually go away .
*/
synchronize_rcu ( ) ;
rcu_barrier ( ) ;
flush_scheduled_work ( ) ;
return AE_OK ;
2018-06-21 16:43:17 +03:00
}
EXPORT_SYMBOL_GPL ( acpi_release_memory ) ;
2010-05-27 21:58:37 +04:00
/*
* Let drivers know whether the resource checks are effective
*/
int acpi_resources_are_enforced ( void )
{
return acpi_enforce_resources = = ENFORCE_RESOURCES_STRICT ;
}
EXPORT_SYMBOL ( acpi_resources_are_enforced ) ;
2011-03-23 12:26:34 +03:00
/*
* Deallocate the memory for a spinlock .
*/
void acpi_os_delete_lock ( acpi_spinlock handle )
{
ACPI_FREE ( handle ) ;
}
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
/*
* Acquire a spinlock .
*
* handle is a pointer to the spinlock_t .
*/
2006-06-24 01:04:00 +04:00
acpi_cpu_flags acpi_os_acquire_lock ( acpi_spinlock lockp )
2020-02-24 02:17:03 +03:00
__acquires ( lockp )
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
{
2006-01-28 00:43:00 +03:00
acpi_cpu_flags flags ;
2006-06-24 01:04:00 +04:00
spin_lock_irqsave ( lockp , flags ) ;
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
return flags ;
}
/*
* Release a spinlock . See above .
*/
2006-06-24 01:04:00 +04:00
void acpi_os_release_lock ( acpi_spinlock lockp , acpi_cpu_flags flags )
2020-02-24 02:17:03 +03:00
__releases ( lockp )
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
{
2006-06-24 01:04:00 +04:00
spin_unlock_irqrestore ( lockp , flags ) ;
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
}
# ifndef ACPI_USE_LOCAL_CACHE
/*******************************************************************************
*
* FUNCTION : acpi_os_create_cache
*
ACPI: ACPICA 20060421
Removed a device initialization optimization introduced in
20051216 where the _STA method was not run unless an _INI
was also present for the same device. This optimization
could cause problems because it could allow _INI methods
to be run within a not-present device subtree (If a
not-present device had no _INI, _STA would not be run,
the not-present status would not be discovered, and the
children of the device would be incorrectly traversed.)
Implemented a new _STA optimization where namespace
subtrees that do not contain _INI are identified and
ignored during device initialization. Selectively running
_STA can significantly improve boot time on large machines
(with assistance from Len Brown.)
Implemented support for the device initialization case
where the returned _STA flags indicate a device not-present
but functioning. In this case, _INI is not run, but the
device children are examined for presence, as per the
ACPI specification.
Implemented an additional change to the IndexField support
in order to conform to MS behavior. The value written to
the Index Register is not simply a byte offset, it is a
byte offset in units of the access width of the parent
Index Field. (Fiodor Suietov)
Defined and deployed a new OSL interface,
acpi_os_validate_address(). This interface is called during
the creation of all AML operation regions, and allows
the host OS to exert control over what addresses it will
allow the AML code to access. Operation Regions whose
addresses are disallowed will cause a runtime exception
when they are actually accessed (will not affect or abort
table loading.)
Defined and deployed a new OSL interface,
acpi_os_validate_interface(). This interface allows the host OS
to match the various "optional" interface/behavior strings
for the _OSI predefined control method as appropriate
(with assistance from Bjorn Helgaas.)
Restructured and corrected various problems in the
exception handling code paths within DsCallControlMethod
and DsTerminateControlMethod in dsmethod (with assistance
from Takayoshi Kochi.)
Modified the Linux source converter to ignore quoted string
literals while converting identifiers from mixed to lower
case. This will correct problems with the disassembler
and other areas where such strings must not be modified.
The ACPI_FUNCTION_* macros no longer require quotes around
the function name. This allows the Linux source converter
to convert the names, now that the converter ignores
quoted strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-22 01:15:00 +04:00
* PARAMETERS : name - Ascii name for the cache
* size - Size of each cached object
* depth - Maximum depth of the cache ( in objects ) < ignored >
* cache - Where the new cache object is returned
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
*
ACPI: ACPICA 20060421
Removed a device initialization optimization introduced in
20051216 where the _STA method was not run unless an _INI
was also present for the same device. This optimization
could cause problems because it could allow _INI methods
to be run within a not-present device subtree (If a
not-present device had no _INI, _STA would not be run,
the not-present status would not be discovered, and the
children of the device would be incorrectly traversed.)
Implemented a new _STA optimization where namespace
subtrees that do not contain _INI are identified and
ignored during device initialization. Selectively running
_STA can significantly improve boot time on large machines
(with assistance from Len Brown.)
Implemented support for the device initialization case
where the returned _STA flags indicate a device not-present
but functioning. In this case, _INI is not run, but the
device children are examined for presence, as per the
ACPI specification.
Implemented an additional change to the IndexField support
in order to conform to MS behavior. The value written to
the Index Register is not simply a byte offset, it is a
byte offset in units of the access width of the parent
Index Field. (Fiodor Suietov)
Defined and deployed a new OSL interface,
acpi_os_validate_address(). This interface is called during
the creation of all AML operation regions, and allows
the host OS to exert control over what addresses it will
allow the AML code to access. Operation Regions whose
addresses are disallowed will cause a runtime exception
when they are actually accessed (will not affect or abort
table loading.)
Defined and deployed a new OSL interface,
acpi_os_validate_interface(). This interface allows the host OS
to match the various "optional" interface/behavior strings
for the _OSI predefined control method as appropriate
(with assistance from Bjorn Helgaas.)
Restructured and corrected various problems in the
exception handling code paths within DsCallControlMethod
and DsTerminateControlMethod in dsmethod (with assistance
from Takayoshi Kochi.)
Modified the Linux source converter to ignore quoted string
literals while converting identifiers from mixed to lower
case. This will correct problems with the disassembler
and other areas where such strings must not be modified.
The ACPI_FUNCTION_* macros no longer require quotes around
the function name. This allows the Linux source converter
to convert the names, now that the converter ignores
quoted strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-22 01:15:00 +04:00
* RETURN : status
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
*
* DESCRIPTION : Create a cache object
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
acpi_status
2005-08-05 08:44:28 +04:00
acpi_os_create_cache ( char * name , u16 size , u16 depth , acpi_cache_t * * cache )
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
{
2007-07-20 05:11:58 +04:00
* cache = kmem_cache_create ( name , size , 0 , 0 , NULL ) ;
2006-12-19 23:56:13 +03:00
if ( * cache = = NULL )
ACPI: ACPICA 20060421
Removed a device initialization optimization introduced in
20051216 where the _STA method was not run unless an _INI
was also present for the same device. This optimization
could cause problems because it could allow _INI methods
to be run within a not-present device subtree (If a
not-present device had no _INI, _STA would not be run,
the not-present status would not be discovered, and the
children of the device would be incorrectly traversed.)
Implemented a new _STA optimization where namespace
subtrees that do not contain _INI are identified and
ignored during device initialization. Selectively running
_STA can significantly improve boot time on large machines
(with assistance from Len Brown.)
Implemented support for the device initialization case
where the returned _STA flags indicate a device not-present
but functioning. In this case, _INI is not run, but the
device children are examined for presence, as per the
ACPI specification.
Implemented an additional change to the IndexField support
in order to conform to MS behavior. The value written to
the Index Register is not simply a byte offset, it is a
byte offset in units of the access width of the parent
Index Field. (Fiodor Suietov)
Defined and deployed a new OSL interface,
acpi_os_validate_address(). This interface is called during
the creation of all AML operation regions, and allows
the host OS to exert control over what addresses it will
allow the AML code to access. Operation Regions whose
addresses are disallowed will cause a runtime exception
when they are actually accessed (will not affect or abort
table loading.)
Defined and deployed a new OSL interface,
acpi_os_validate_interface(). This interface allows the host OS
to match the various "optional" interface/behavior strings
for the _OSI predefined control method as appropriate
(with assistance from Bjorn Helgaas.)
Restructured and corrected various problems in the
exception handling code paths within DsCallControlMethod
and DsTerminateControlMethod in dsmethod (with assistance
from Takayoshi Kochi.)
Modified the Linux source converter to ignore quoted string
literals while converting identifiers from mixed to lower
case. This will correct problems with the disassembler
and other areas where such strings must not be modified.
The ACPI_FUNCTION_* macros no longer require quotes around
the function name. This allows the Linux source converter
to convert the names, now that the converter ignores
quoted strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-22 01:15:00 +04:00
return AE_ERROR ;
else
return AE_OK ;
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
}
/*******************************************************************************
*
* FUNCTION : acpi_os_purge_cache
*
* PARAMETERS : Cache - Handle to cache object
*
* RETURN : Status
*
* DESCRIPTION : Free all objects within the requested cache .
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_purge_cache ( acpi_cache_t * cache )
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
{
2006-10-01 02:28:50 +04:00
kmem_cache_shrink ( cache ) ;
2005-08-05 08:44:28 +04:00
return ( AE_OK ) ;
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
}
/*******************************************************************************
*
* FUNCTION : acpi_os_delete_cache
*
* PARAMETERS : Cache - Handle to cache object
*
* RETURN : Status
*
* DESCRIPTION : Free all objects within the requested cache and delete the
* cache object .
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_delete_cache ( acpi_cache_t * cache )
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
{
2006-09-27 12:49:40 +04:00
kmem_cache_destroy ( cache ) ;
2005-08-05 08:44:28 +04:00
return ( AE_OK ) ;
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
}
/*******************************************************************************
*
* FUNCTION : acpi_os_release_object
*
* PARAMETERS : Cache - Handle to cache object
* Object - The object to be released
*
* RETURN : None
*
* DESCRIPTION : Release an object to the specified cache . If cache is full ,
* the object is deleted .
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2005-08-05 08:44:28 +04:00
acpi_status acpi_os_release_object ( acpi_cache_t * cache , void * object )
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
{
2005-08-05 08:44:28 +04:00
kmem_cache_free ( cache , object ) ;
return ( AE_OK ) ;
ACPICA 20050617-0624 from Bob Moore <robert.moore@intel.com>
ACPICA 20050617:
Moved the object cache operations into the OS interface
layer (OSL) to allow the host OS to handle these operations
if desired (for example, the Linux OSL will invoke the
slab allocator). This support is optional; the compile
time define ACPI_USE_LOCAL_CACHE may be used to utilize
the original cache code in the ACPI CA core. The new OSL
interfaces are shown below. See utalloc.c for an example
implementation, and acpiosxf.h for the exact interface
definitions. Thanks to Alexey Starikovskiy.
acpi_os_create_cache
acpi_os_delete_cache
acpi_os_purge_cache
acpi_os_acquire_object
acpi_os_release_object
Modified the interfaces to acpi_os_acquire_lock and
acpi_os_release_lock to return and restore a flags
parameter. This fits better with many OS lock models.
Note: the current execution state (interrupt handler
or not) is no longer passed to these interfaces. If
necessary, the OSL must determine this state by itself, a
simple and fast operation. Thanks to Alexey Starikovskiy.
Fixed a problem in the ACPI table handling where a valid
XSDT was assumed present if the revision of the RSDP
was 2 or greater. According to the ACPI specification,
the XSDT is optional in all cases, and the table manager
therefore now checks for both an RSDP >=2 and a valid
XSDT pointer. Otherwise, the RSDT pointer is used.
Some ACPI 2.0 compliant BIOSs contain only the RSDT.
Fixed an interpreter problem with the Mid() operator in the
case of an input string where the resulting output string
is of zero length. It now correctly returns a valid,
null terminated string object instead of a string object
with a null pointer.
Fixed a problem with the control method argument handling
to allow a store to an Arg object that already contains an
object of type Device. The Device object is now correctly
overwritten. Previously, an error was returned.
ACPICA 20050624:
Modified the new OSL cache interfaces to use ACPI_CACHE_T
as the type for the host-defined cache object. This allows
the OSL implementation to define and type this object in
any manner desired, simplifying the OSL implementation.
For example, ACPI_CACHE_T is defined as kmem_cache_t for
Linux, and should be defined in the OS-specific header
file for other operating systems as required.
Changed the interface to AcpiOsAcquireObject to directly
return the requested object as the function return (instead
of ACPI_STATUS.) This change was made for performance
reasons, since this is the purpose of the interface in the
first place. acpi_os_acquire_object is now similar to the
acpi_os_allocate interface. Thanks to Alexey Starikovskiy.
Modified the initialization sequence in
acpi_initialize_subsystem to call the OSL interface
acpi_osl_initialize first, before any local initialization.
This change was required because the global initialization
now calls OSL interfaces.
Restructured the code base to split some files because
of size and/or because the code logically belonged in a
separate file. New files are listed below.
utilities/utcache.c /* Local cache interfaces */
utilities/utmutex.c /* Local mutex support */
utilities/utstate.c /* State object support */
parser/psloop.c /* Main AML parse loop */
Signed-off-by: Len Brown <len.brown@intel.com>
2005-06-24 08:00:00 +04:00
}
# endif
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
2014-04-04 08:39:11 +04:00
static int __init acpi_no_static_ssdt_setup ( char * s )
2013-06-08 04:58:48 +04:00
{
2014-04-04 08:39:11 +04:00
acpi_gbl_disable_ssdt_table_install = TRUE ;
pr_info ( " ACPI: static SSDT installation disabled \n " ) ;
2013-06-08 04:58:48 +04:00
2014-04-04 08:39:11 +04:00
return 0 ;
2013-06-08 04:58:48 +04:00
}
2014-04-04 08:39:11 +04:00
early_param ( " acpi_no_static_ssdt " , acpi_no_static_ssdt_setup ) ;
2013-06-08 04:58:48 +04:00
2014-02-11 07:01:52 +04:00
static int __init acpi_disable_return_repair ( char * s )
{
printk ( KERN_NOTICE PREFIX
" ACPI: Predefined validation mechanism disabled \n " ) ;
acpi_gbl_disable_auto_repair = TRUE ;
return 1 ;
}
__setup ( " acpica_no_return_repair " , acpi_disable_return_repair ) ;
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
acpi_status __init acpi_os_initialize ( void )
{
acpi_os_map_generic_address ( & acpi_gbl_FADT . xpm1a_event_block ) ;
acpi_os_map_generic_address ( & acpi_gbl_FADT . xpm1b_event_block ) ;
2020-09-11 15:59:42 +03:00
acpi_gbl_xgpe0_block_logical_address =
( unsigned long ) acpi_os_map_generic_address ( & acpi_gbl_FADT . xgpe0_block ) ;
acpi_gbl_xgpe1_block_logical_address =
( unsigned long ) acpi_os_map_generic_address ( & acpi_gbl_FADT . xgpe1_block ) ;
2014-06-04 19:55:59 +04:00
if ( acpi_gbl_FADT . flags & ACPI_FADT_RESET_REGISTER ) {
/*
* Use acpi_os_map_generic_address to pre - map the reset
* register if it ' s in system memory .
*/
2020-09-11 15:59:35 +03:00
void * rv ;
2014-06-04 19:55:59 +04:00
rv = acpi_os_map_generic_address ( & acpi_gbl_FADT . reset_register ) ;
2020-09-11 15:59:35 +03:00
pr_debug ( PREFIX " %s: map reset_reg %s \n " , __func__ ,
rv ? " successful " : " failed " ) ;
2014-06-04 19:55:59 +04:00
}
2015-08-05 11:23:51 +03:00
acpi_os_initialized = true ;
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
return AE_OK ;
}
2010-12-08 05:40:36 +03:00
acpi_status __init acpi_os_initialize1 ( void )
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
{
2011-02-01 13:42:42 +03:00
kacpid_wq = alloc_workqueue ( " kacpid " , 0 , 1 ) ;
kacpi_notify_wq = alloc_workqueue ( " kacpi_notify " , 0 , 1 ) ;
2013-11-23 00:52:12 +04:00
kacpi_hotplug_wq = alloc_ordered_workqueue ( " kacpi_hotplug " , 0 ) ;
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
BUG_ON ( ! kacpid_wq ) ;
BUG_ON ( ! kacpi_notify_wq ) ;
BUG_ON ( ! kacpi_hotplug_wq ) ;
2016-05-03 11:49:01 +03:00
acpi_osi_init ( ) ;
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
return AE_OK ;
}
acpi_status acpi_os_terminate ( void )
{
if ( acpi_irq_handler ) {
2011-02-09 01:48:16 +03:00
acpi_os_remove_interrupt_handler ( acpi_gbl_FADT . sci_interrupt ,
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
acpi_irq_handler ) ;
}
acpi_os_unmap_generic_address ( & acpi_gbl_FADT . xgpe1_block ) ;
acpi_os_unmap_generic_address ( & acpi_gbl_FADT . xgpe0_block ) ;
2020-09-11 15:59:42 +03:00
acpi_gbl_xgpe0_block_logical_address = 0UL ;
acpi_gbl_xgpe1_block_logical_address = 0UL ;
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
acpi_os_unmap_generic_address ( & acpi_gbl_FADT . xpm1b_event_block ) ;
acpi_os_unmap_generic_address ( & acpi_gbl_FADT . xpm1a_event_block ) ;
2020-09-11 15:59:42 +03:00
2014-06-04 19:55:59 +04:00
if ( acpi_gbl_FADT . flags & ACPI_FADT_RESET_REGISTER )
acpi_os_unmap_generic_address ( & acpi_gbl_FADT . reset_register ) ;
ACPI: Pre-map 'system event' related register blocks
During ACPI initialization, pre-map fixed hardware registers that are
accessed during ACPI's 'system event' related IRQ handing.
ACPI's 'system event' handing accesses specific fixed hardware
registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
blocks which are declared within the FADT. If these registers are
backed by MMIO, as opposed to I/O port space, accessing them within
interrupt context will cause a panic as acpi_os_read_memory()
depends on ioremap() in such cases - BZ 18012.
By utilizing the functionality provided in the previous two patches -
ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
Add interfaces for ioremapping/iounmapping ACPI registers - accesses
to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
and/or NMI) provided the area was pre-mapped. This solves BZ 18012.
ACPI "System Event" reference(s):
ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
3.8 "System Events", 5.6 "ACPI Event Programming Model".
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
Reported-by: <bjorn.helgaas@hp.com>
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-10-22 00:24:04 +04:00
destroy_workqueue ( kacpid_wq ) ;
destroy_workqueue ( kacpi_notify_wq ) ;
destroy_workqueue ( kacpi_hotplug_wq ) ;
return AE_OK ;
}
2011-12-09 06:05:54 +04:00
acpi_status acpi_os_prepare_sleep ( u8 sleep_state , u32 pm1a_control ,
u32 pm1b_control )
{
int rc = 0 ;
if ( __acpi_os_prepare_sleep )
rc = __acpi_os_prepare_sleep ( sleep_state ,
pm1a_control , pm1b_control ) ;
if ( rc < 0 )
return AE_ERROR ;
else if ( rc > 0 )
2016-12-28 10:28:49 +03:00
return AE_CTRL_TERMINATE ;
2011-12-09 06:05:54 +04:00
return AE_OK ;
}
void acpi_os_set_prepare_sleep ( int ( * func ) ( u8 sleep_state ,
u32 pm1a_ctrl , u32 pm1b_ctrl ) )
{
__acpi_os_prepare_sleep = func ;
}
2013-01-22 01:20:47 +04:00
2016-12-28 10:28:49 +03:00
# if (ACPI_REDUCED_HARDWARE)
2013-07-30 16:24:52 +04:00
acpi_status acpi_os_prepare_extended_sleep ( u8 sleep_state , u32 val_a ,
u32 val_b )
{
int rc = 0 ;
if ( __acpi_os_prepare_extended_sleep )
rc = __acpi_os_prepare_extended_sleep ( sleep_state ,
val_a , val_b ) ;
if ( rc < 0 )
return AE_ERROR ;
else if ( rc > 0 )
2016-12-28 10:28:49 +03:00
return AE_CTRL_TERMINATE ;
2013-07-30 16:24:52 +04:00
return AE_OK ;
}
2016-12-28 10:28:49 +03:00
# else
acpi_status acpi_os_prepare_extended_sleep ( u8 sleep_state , u32 val_a ,
u32 val_b )
{
return AE_OK ;
}
# endif
2013-07-30 16:24:52 +04:00
void acpi_os_set_prepare_extended_sleep ( int ( * func ) ( u8 sleep_state ,
u32 val_a , u32 val_b ) )
{
__acpi_os_prepare_extended_sleep = func ;
}
2016-12-28 10:28:49 +03:00
acpi_status acpi_os_enter_sleep ( u8 sleep_state ,
u32 reg_a_value , u32 reg_b_value )
{
acpi_status status ;
if ( acpi_gbl_reduced_hardware )
status = acpi_os_prepare_extended_sleep ( sleep_state ,
reg_a_value ,
reg_b_value ) ;
else
status = acpi_os_prepare_sleep ( sleep_state ,
reg_a_value , reg_b_value ) ;
return status ;
}