2005-04-17 00:20:36 +02:00
|
|
|
/*
|
|
|
|
|
* acpi_drivers.h ($Revision: 31 $)
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2001, 2002 Andy Grover <andrew.grover@intel.com>
|
|
|
|
|
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenbaugh@intel.com>
|
|
|
|
|
*
|
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or (at
|
|
|
|
|
* your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
|
|
|
|
|
*
|
|
|
|
|
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __ACPI_DRIVERS_H__
|
|
|
|
|
#define __ACPI_DRIVERS_H__
|
|
|
|
|
|
|
|
|
|
#define ACPI_MAX_STRING 80
|
|
|
|
|
|
2008-11-08 00:57:55 +01:00
|
|
|
/*
|
|
|
|
|
* Please update drivers/acpi/debug.c and Documentation/acpi/debug.txt
|
|
|
|
|
* if you add to this list.
|
|
|
|
|
*/
|
2005-04-17 00:20:36 +02:00
|
|
|
#define ACPI_BUS_COMPONENT 0x00010000
|
2008-11-08 00:57:45 +01:00
|
|
|
#define ACPI_AC_COMPONENT 0x00020000
|
|
|
|
|
#define ACPI_BATTERY_COMPONENT 0x00040000
|
|
|
|
|
#define ACPI_BUTTON_COMPONENT 0x00080000
|
2008-11-08 00:57:50 +01:00
|
|
|
#define ACPI_SBS_COMPONENT 0x00100000
|
2008-11-08 00:57:45 +01:00
|
|
|
#define ACPI_FAN_COMPONENT 0x00200000
|
|
|
|
|
#define ACPI_PCI_COMPONENT 0x00400000
|
|
|
|
|
#define ACPI_POWER_COMPONENT 0x00800000
|
|
|
|
|
#define ACPI_CONTAINER_COMPONENT 0x01000000
|
2005-04-17 00:20:36 +02:00
|
|
|
#define ACPI_SYSTEM_COMPONENT 0x02000000
|
2008-11-08 00:57:45 +01:00
|
|
|
#define ACPI_THERMAL_COMPONENT 0x04000000
|
|
|
|
|
#define ACPI_MEMORY_DEVICE_COMPONENT 0x08000000
|
2008-11-08 00:57:50 +01:00
|
|
|
#define ACPI_VIDEO_COMPONENT 0x10000000
|
|
|
|
|
#define ACPI_PROCESSOR_COMPONENT 0x20000000
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2007-07-23 14:43:32 +02:00
|
|
|
/*
|
|
|
|
|
* _HID definitions
|
|
|
|
|
* HIDs must conform to ACPI spec(6.1.4)
|
|
|
|
|
* Linux specific HIDs do not apply to this and begin with LNX:
|
|
|
|
|
*/
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2007-07-23 14:43:32 +02:00
|
|
|
#define ACPI_POWER_HID "LNXPOWER"
|
2009-04-28 00:33:36 +02:00
|
|
|
#define ACPI_PROCESSOR_OBJECT_HID "LNXCPU"
|
2007-07-23 14:43:32 +02:00
|
|
|
#define ACPI_SYSTEM_HID "LNXSYSTM"
|
|
|
|
|
#define ACPI_THERMAL_HID "LNXTHERM"
|
|
|
|
|
#define ACPI_BUTTON_HID_POWERF "LNXPWRBN"
|
|
|
|
|
#define ACPI_BUTTON_HID_SLEEPF "LNXSLPBN"
|
|
|
|
|
#define ACPI_VIDEO_HID "LNXVIDEO"
|
|
|
|
|
#define ACPI_BAY_HID "LNXIOBAY"
|
2007-12-07 13:20:42 +01:00
|
|
|
#define ACPI_DOCK_HID "LNXDOCK"
|
2010-03-24 14:38:37 +01:00
|
|
|
/* Quirk for broken IBM BIOSes */
|
|
|
|
|
#define ACPI_SMBUS_IBM_HID "SMBUSIBM"
|
2007-07-23 14:43:32 +02:00
|
|
|
|
2009-03-30 19:48:13 +02:00
|
|
|
/*
|
|
|
|
|
* For fixed hardware buttons, we fabricate acpi_devices with HID
|
|
|
|
|
* ACPI_BUTTON_HID_POWERF or ACPI_BUTTON_HID_SLEEPF. Fixed hardware
|
|
|
|
|
* signals only an event; it doesn't supply a notification value.
|
|
|
|
|
* To allow drivers to treat notifications from fixed hardware the
|
|
|
|
|
* same as those from real devices, we turn the events into this
|
|
|
|
|
* notification value.
|
|
|
|
|
*/
|
|
|
|
|
#define ACPI_FIXED_HARDWARE_EVENT 0x100
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
|
PCI
|
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* ACPI PCI Interrupt Link (pci_link.c) */
|
|
|
|
|
|
2005-08-05 06:44:28 +02:00
|
|
|
int acpi_irq_penalty_init(void);
|
[ACPI] ACPICA 20050930
Completed a major overhaul of the Resource Manager code -
specifically, optimizations in the area of the AML/internal
resource conversion code. The code has been optimized to
simplify and eliminate duplicated code, CPU stack use has
been decreased by optimizing function parameters and local
variables, and naming conventions across the manager have
been standardized for clarity and ease of maintenance (this
includes function, parameter, variable, and struct/typedef
names.)
All Resource Manager dispatch and information tables have
been moved to a single location for clarity and ease of
maintenance. One new file was created, named "rsinfo.c".
The ACPI return macros (return_ACPI_STATUS, etc.) have
been modified to guarantee that the argument is
not evaluated twice, making them less prone to macro
side-effects. However, since there exists the possibility
of additional stack use if a particular compiler cannot
optimize them (such as in the debug generation case),
the original macros are optionally available. Note that
some invocations of the return_VALUE macro may now cause
size mismatch warnings; the return_UINT8 and return_UINT32
macros are provided to eliminate these. (From Randy Dunlap)
Implemented a new mechanism to enable debug tracing for
individual control methods. A new external interface,
acpi_debug_trace(), is provided to enable this mechanism. The
intent is to allow the host OS to easily enable and disable
tracing for problematic control methods. This interface
can be easily exposed to a user or debugger interface if
desired. See the file psxface.c for details.
acpi_ut_callocate() will now return a valid pointer if a
length of zero is specified - a length of one is used
and a warning is issued. This matches the behavior of
acpi_ut_allocate().
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 01:03:00 +02:00
|
|
|
int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering,
|
|
|
|
|
int *polarity, char **name);
|
2005-07-28 05:02:00 +02:00
|
|
|
int acpi_pci_link_free_irq(acpi_handle handle);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
/* ACPI PCI Device Binding (pci_bind.c) */
|
|
|
|
|
|
|
|
|
|
struct pci_bus;
|
|
|
|
|
|
2009-06-10 21:55:20 +02:00
|
|
|
struct pci_dev *acpi_get_pci_dev(acpi_handle);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
/* Arch-defined function to add a bus to the system */
|
|
|
|
|
|
2010-03-11 20:20:11 +01:00
|
|
|
struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root);
|
2010-02-23 18:24:41 +01:00
|
|
|
void pci_acpi_crs_quirks(void);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
/* --------------------------------------------------------------------------
|
|
|
|
|
Processor
|
|
|
|
|
-------------------------------------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
#define ACPI_PROCESSOR_LIMIT_NONE 0x00
|
|
|
|
|
#define ACPI_PROCESSOR_LIMIT_INCREMENT 0x01
|
|
|
|
|
#define ACPI_PROCESSOR_LIMIT_DECREMENT 0x02
|
|
|
|
|
|
2006-07-09 23:22:28 +02:00
|
|
|
/*--------------------------------------------------------------------------
|
|
|
|
|
Dock Station
|
|
|
|
|
-------------------------------------------------------------------------- */
|
2008-08-28 04:06:16 +02:00
|
|
|
struct acpi_dock_ops {
|
2013-07-05 03:03:25 +02:00
|
|
|
acpi_notify_handler fixup;
|
2008-08-28 04:06:16 +02:00
|
|
|
acpi_notify_handler handler;
|
|
|
|
|
acpi_notify_handler uevent;
|
|
|
|
|
};
|
|
|
|
|
|
2013-07-05 03:02:25 +02:00
|
|
|
#ifdef CONFIG_ACPI_DOCK
|
2006-07-09 23:22:28 +02:00
|
|
|
extern int is_dock_device(acpi_handle handle);
|
|
|
|
|
extern int register_hotplug_dock_device(acpi_handle handle,
|
2011-06-25 19:07:52 +02:00
|
|
|
const struct acpi_dock_ops *ops,
|
ACPI / dock / PCI: Synchronous handling of dock events for PCI devices
The interactions between the ACPI dock driver and the ACPI-based PCI
hotplug (acpiphp) are currently problematic because of ordering
issues during hot-remove operations.
First of all, the current ACPI glue code expects that physical
devices will always be deleted before deleting the companion ACPI
device objects. Otherwise, acpi_unbind_one() will fail with a
warning message printed to the kernel log, for example:
[ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt
[ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
[ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
[ 180.013656] port1: Oops, 'acpi_handle' corrupt
This means, in particular, that struct pci_dev objects have to
be deleted before the struct acpi_device objects they are "glued"
with.
Now, the following happens the during the undocking of an ACPI-based
dock station:
1) hotplug_dock_devices() invokes registered hotplug callbacks to
destroy physical devices associated with the ACPI device objects
depending on the dock station. It calls dd->ops->handler() for
each of those device objects.
2) For PCI devices dd->ops->handler() points to
handle_hotplug_event_func() that queues up a separate work item
to execute _handle_hotplug_event_func() for the given device and
returns immediately. That work item will be executed later.
3) hotplug_dock_devices() calls dock_remove_acpi_device() for each
device depending on the dock station. This runs acpi_bus_trim()
for each of them, which causes the underlying ACPI device object
to be destroyed, but the work items queued up by
handle_hotplug_event_func() haven't been started yet.
4) _handle_hotplug_event_func() queued up in step 2) are executed
and cause the above failure to happen, because the PCI devices
they handle do not have the companion ACPI device objects any
more (those objects have been deleted in step 3).
The possible breakage doesn't end here, though, because
hotplug_dock_devices() may return before at least some of the
_handle_hotplug_event_func() work items spawned by it have a
chance to complete and then undock() will cause _DCK to be
evaluated and that will cause the devices handled by the
_handle_hotplug_event_func() to go away possibly while they are
being accessed.
This means that dd->ops->handler() for PCI devices should not point
to handle_hotplug_event_func(). Instead, it should point to a
function that will do the work of _handle_hotplug_event_func()
synchronously. For this reason, introduce such a function,
hotplug_event_func(), and modity acpiphp_dock_ops to point to
it as the handler.
Unfortunately, however, this is not sufficient, because if the dock
code were not changed further, hotplug_event_func() would now
deadlock with hotplug_dock_devices() that called it, since it would
run unregister_hotplug_dock_device() which in turn would attempt to
acquire the dock station's hp_lock mutex already acquired by
hotplug_dock_devices().
To resolve that deadlock use the observation that
unregister_hotplug_dock_device() won't need to acquire hp_lock
if PCI bridges the devices on the dock station depend on are
prevented from being removed prematurely while the first loop in
hotplug_dock_devices() is in progress.
To make that possible, introduce a mechanism by which the callers of
register_hotplug_dock_device() can provide "init" and "release"
routines that will be executed, respectively, during the addition
and removal of the physical device object associated with the
given ACPI device handle. Make acpiphp use two new functions,
acpiphp_dock_init() and acpiphp_dock_release(), that call
get_bridge() and put_bridge(), respectively, on the acpiphp bridge
holding the given device, for this purpose.
In addition to that, remove the dock station's list of
"hotplug devices" and make the dock code always walk the whole list
of "dependent devices" instead in such a way that the loops in
hotplug_dock_devices() and dock_event() (replacing the loops over
"hotplug devices") will take references to the list entries that
register_hotplug_dock_device() has been called for. That prevents
the "release" routines associated with those entries from being
called while the given entry is being processed and for PCI
devices this means that their bridges won't be removed (by a
concurrent thread) while hotplug_event_func() handling them is
being executed.
This change is based on two earlier patches from Jiang Liu.
References: https://bugzilla.kernel.org/show_bug.cgi?id=59501
Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com>
Tracked-down-by: Jiang Liu <jiang.liu@huawei.com>
Tested-by: Illya Klymov <xanf@xanf.me>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: 3.9+ <stable@vger.kernel.org>
2013-06-24 11:22:53 +02:00
|
|
|
void *context,
|
|
|
|
|
void (*init)(void *),
|
|
|
|
|
void (*release)(void *));
|
2006-07-09 23:22:28 +02:00
|
|
|
extern void unregister_hotplug_dock_device(acpi_handle handle);
|
|
|
|
|
#else
|
2007-02-08 01:51:46 +01:00
|
|
|
static inline int is_dock_device(acpi_handle handle)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
static inline int register_hotplug_dock_device(acpi_handle handle,
|
2011-11-02 20:16:05 +01:00
|
|
|
const struct acpi_dock_ops *ops,
|
ACPI / dock / PCI: Synchronous handling of dock events for PCI devices
The interactions between the ACPI dock driver and the ACPI-based PCI
hotplug (acpiphp) are currently problematic because of ordering
issues during hot-remove operations.
First of all, the current ACPI glue code expects that physical
devices will always be deleted before deleting the companion ACPI
device objects. Otherwise, acpi_unbind_one() will fail with a
warning message printed to the kernel log, for example:
[ 185.026073] usb usb5: Oops, 'acpi_handle' corrupt
[ 185.035150] pci 0000:1b:00.0: Oops, 'acpi_handle' corrupt
[ 185.035515] pci 0000:18:02.0: Oops, 'acpi_handle' corrupt
[ 180.013656] port1: Oops, 'acpi_handle' corrupt
This means, in particular, that struct pci_dev objects have to
be deleted before the struct acpi_device objects they are "glued"
with.
Now, the following happens the during the undocking of an ACPI-based
dock station:
1) hotplug_dock_devices() invokes registered hotplug callbacks to
destroy physical devices associated with the ACPI device objects
depending on the dock station. It calls dd->ops->handler() for
each of those device objects.
2) For PCI devices dd->ops->handler() points to
handle_hotplug_event_func() that queues up a separate work item
to execute _handle_hotplug_event_func() for the given device and
returns immediately. That work item will be executed later.
3) hotplug_dock_devices() calls dock_remove_acpi_device() for each
device depending on the dock station. This runs acpi_bus_trim()
for each of them, which causes the underlying ACPI device object
to be destroyed, but the work items queued up by
handle_hotplug_event_func() haven't been started yet.
4) _handle_hotplug_event_func() queued up in step 2) are executed
and cause the above failure to happen, because the PCI devices
they handle do not have the companion ACPI device objects any
more (those objects have been deleted in step 3).
The possible breakage doesn't end here, though, because
hotplug_dock_devices() may return before at least some of the
_handle_hotplug_event_func() work items spawned by it have a
chance to complete and then undock() will cause _DCK to be
evaluated and that will cause the devices handled by the
_handle_hotplug_event_func() to go away possibly while they are
being accessed.
This means that dd->ops->handler() for PCI devices should not point
to handle_hotplug_event_func(). Instead, it should point to a
function that will do the work of _handle_hotplug_event_func()
synchronously. For this reason, introduce such a function,
hotplug_event_func(), and modity acpiphp_dock_ops to point to
it as the handler.
Unfortunately, however, this is not sufficient, because if the dock
code were not changed further, hotplug_event_func() would now
deadlock with hotplug_dock_devices() that called it, since it would
run unregister_hotplug_dock_device() which in turn would attempt to
acquire the dock station's hp_lock mutex already acquired by
hotplug_dock_devices().
To resolve that deadlock use the observation that
unregister_hotplug_dock_device() won't need to acquire hp_lock
if PCI bridges the devices on the dock station depend on are
prevented from being removed prematurely while the first loop in
hotplug_dock_devices() is in progress.
To make that possible, introduce a mechanism by which the callers of
register_hotplug_dock_device() can provide "init" and "release"
routines that will be executed, respectively, during the addition
and removal of the physical device object associated with the
given ACPI device handle. Make acpiphp use two new functions,
acpiphp_dock_init() and acpiphp_dock_release(), that call
get_bridge() and put_bridge(), respectively, on the acpiphp bridge
holding the given device, for this purpose.
In addition to that, remove the dock station's list of
"hotplug devices" and make the dock code always walk the whole list
of "dependent devices" instead in such a way that the loops in
hotplug_dock_devices() and dock_event() (replacing the loops over
"hotplug devices") will take references to the list entries that
register_hotplug_dock_device() has been called for. That prevents
the "release" routines associated with those entries from being
called while the given entry is being processed and for PCI
devices this means that their bridges won't be removed (by a
concurrent thread) while hotplug_event_func() handling them is
being executed.
This change is based on two earlier patches from Jiang Liu.
References: https://bugzilla.kernel.org/show_bug.cgi?id=59501
Reported-and-tested-by: Alexander E. Patrakov <patrakov@gmail.com>
Tracked-down-by: Jiang Liu <jiang.liu@huawei.com>
Tested-by: Illya Klymov <xanf@xanf.me>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Yinghai Lu <yinghai@kernel.org>
Cc: 3.9+ <stable@vger.kernel.org>
2013-06-24 11:22:53 +02:00
|
|
|
void *context,
|
|
|
|
|
void (*init)(void *),
|
|
|
|
|
void (*release)(void *))
|
2007-02-08 01:51:46 +01:00
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
static inline void unregister_hotplug_dock_device(acpi_handle handle)
|
|
|
|
|
{
|
|
|
|
|
}
|
2013-07-05 03:02:25 +02:00
|
|
|
#endif /* CONFIG_ACPI_DOCK */
|
2007-02-10 07:32:16 +01:00
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
#endif /*__ACPI_DRIVERS_H__*/
|