2019-05-27 14:55:06 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2006-07-10 05:22:28 +08:00
|
|
|
/*
|
|
|
|
|
* dock.c - ACPI dock station driver
|
|
|
|
|
*
|
2014-02-21 08:11:46 +08:00
|
|
|
* Copyright (C) 2006, 2014, Intel Corp.
|
|
|
|
|
* Author: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
|
|
|
|
|
* Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
2006-07-10 05:22:28 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
2016-07-12 04:23:26 +08:00
|
|
|
#include <linux/moduleparam.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2006-07-10 05:22:28 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/notifier.h>
|
2006-12-05 06:49:43 +08:00
|
|
|
#include <linux/platform_device.h>
|
2006-10-19 01:55:46 +08:00
|
|
|
#include <linux/jiffies.h>
|
2007-03-27 13:38:49 +08:00
|
|
|
#include <linux/stddef.h>
|
2012-11-21 07:42:30 +08:00
|
|
|
#include <linux/acpi.h>
|
2006-07-10 05:22:28 +08:00
|
|
|
|
2013-12-17 17:30:04 +08:00
|
|
|
#include "internal.h"
|
|
|
|
|
|
2012-01-13 07:02:20 +08:00
|
|
|
static bool immediate_undock = 1;
|
2007-05-10 06:08:15 +08:00
|
|
|
module_param(immediate_undock, bool, 0644);
|
|
|
|
|
MODULE_PARM_DESC(immediate_undock, "1 (default) will cause the driver to "
|
|
|
|
|
"undock immediately when the undock button is pressed, 0 will cause"
|
|
|
|
|
" the driver to wait for userspace to write the undock sysfs file "
|
|
|
|
|
" before undocking");
|
|
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
struct dock_station {
|
|
|
|
|
acpi_handle handle;
|
|
|
|
|
unsigned long last_dock_time;
|
|
|
|
|
u32 flags;
|
|
|
|
|
struct list_head dependent_devices;
|
2008-08-28 10:03:58 +08:00
|
|
|
|
2009-10-02 01:59:23 +08:00
|
|
|
struct list_head sibling;
|
2008-08-28 10:03:58 +08:00
|
|
|
struct platform_device *dock_device;
|
2006-07-10 05:22:28 +08:00
|
|
|
};
|
2008-08-28 10:03:58 +08:00
|
|
|
static LIST_HEAD(dock_stations);
|
|
|
|
|
static int dock_station_count;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
|
|
|
|
struct dock_dependent_device {
|
|
|
|
|
struct list_head list;
|
2014-02-21 08:10:09 +08:00
|
|
|
struct acpi_device *adev;
|
2006-07-10 05:22:28 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define DOCK_DOCKING 0x00000001
|
2007-05-10 06:08:15 +08:00
|
|
|
#define DOCK_UNDOCKING 0x00000002
|
2008-08-28 10:03:58 +08:00
|
|
|
#define DOCK_IS_DOCK 0x00000010
|
|
|
|
|
#define DOCK_IS_ATA 0x00000020
|
|
|
|
|
#define DOCK_IS_BAT 0x00000040
|
2006-08-02 05:59:19 +08:00
|
|
|
#define DOCK_EVENT 3
|
|
|
|
|
#define UNDOCK_EVENT 2
|
2006-07-10 05:22:28 +08:00
|
|
|
|
2013-07-05 09:03:25 +08:00
|
|
|
enum dock_callback_type {
|
|
|
|
|
DOCK_CALL_HANDLER,
|
|
|
|
|
DOCK_CALL_FIXUP,
|
|
|
|
|
DOCK_CALL_UEVENT,
|
|
|
|
|
};
|
|
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/*****************************************************************************
|
|
|
|
|
* Dock Dependent device functions *
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
/**
|
2009-10-20 05:14:29 +08:00
|
|
|
* add_dock_dependent_device - associate a device with the dock station
|
2014-02-21 08:10:09 +08:00
|
|
|
* @ds: Dock station.
|
|
|
|
|
* @adev: Dependent ACPI device object.
|
2006-07-10 05:22:28 +08:00
|
|
|
*
|
2009-10-20 05:14:29 +08:00
|
|
|
* Add the dependent device to the dock's dependent device list.
|
2006-07-10 05:22:28 +08:00
|
|
|
*/
|
2014-02-21 08:10:09 +08:00
|
|
|
static int add_dock_dependent_device(struct dock_station *ds,
|
|
|
|
|
struct acpi_device *adev)
|
2006-07-10 05:22:28 +08:00
|
|
|
{
|
|
|
|
|
struct dock_dependent_device *dd;
|
|
|
|
|
|
|
|
|
|
dd = kzalloc(sizeof(*dd), GFP_KERNEL);
|
2009-10-20 05:14:29 +08:00
|
|
|
if (!dd)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2014-02-21 08:10:09 +08:00
|
|
|
dd->adev = adev;
|
2009-10-20 05:14:29 +08:00
|
|
|
INIT_LIST_HEAD(&dd->list);
|
2006-07-10 05:22:28 +08:00
|
|
|
list_add_tail(&dd->list, &ds->dependent_devices);
|
2009-10-20 05:14:29 +08:00
|
|
|
|
|
|
|
|
return 0;
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
|
|
|
|
|
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 17:22:53 +08:00
|
|
|
static void dock_hotplug_event(struct dock_dependent_device *dd, u32 event,
|
2013-07-05 09:03:25 +08:00
|
|
|
enum dock_callback_type cb_type)
|
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 17:22:53 +08:00
|
|
|
{
|
2014-02-21 08:10:18 +08:00
|
|
|
struct acpi_device *adev = dd->adev;
|
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 17:22:53 +08:00
|
|
|
|
2014-02-21 08:10:18 +08:00
|
|
|
acpi_lock_hp_context();
|
|
|
|
|
|
|
|
|
|
if (!adev->hp)
|
2014-02-21 08:11:30 +08:00
|
|
|
goto out;
|
2014-02-21 08:10:18 +08:00
|
|
|
|
|
|
|
|
if (cb_type == DOCK_CALL_FIXUP) {
|
|
|
|
|
void (*fixup)(struct acpi_device *);
|
|
|
|
|
|
|
|
|
|
fixup = adev->hp->fixup;
|
|
|
|
|
if (fixup) {
|
|
|
|
|
acpi_unlock_hp_context();
|
|
|
|
|
fixup(adev);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2014-02-21 08:10:27 +08:00
|
|
|
} else if (cb_type == DOCK_CALL_UEVENT) {
|
|
|
|
|
void (*uevent)(struct acpi_device *, u32);
|
|
|
|
|
|
|
|
|
|
uevent = adev->hp->uevent;
|
|
|
|
|
if (uevent) {
|
|
|
|
|
acpi_unlock_hp_context();
|
|
|
|
|
uevent(adev, event);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2014-02-21 08:10:18 +08:00
|
|
|
} else {
|
|
|
|
|
int (*notify)(struct acpi_device *, u32);
|
|
|
|
|
|
2014-02-21 08:10:27 +08:00
|
|
|
notify = adev->hp->notify;
|
2014-02-21 08:10:18 +08:00
|
|
|
if (notify) {
|
|
|
|
|
acpi_unlock_hp_context();
|
|
|
|
|
notify(adev, event);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-02-21 08:11:30 +08:00
|
|
|
out:
|
2014-02-21 08:10:18 +08:00
|
|
|
acpi_unlock_hp_context();
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
|
|
|
|
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
static struct dock_station *find_dock_station(acpi_handle handle)
|
|
|
|
|
{
|
|
|
|
|
struct dock_station *ds;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(ds, &dock_stations, sibling)
|
|
|
|
|
if (ds->handle == handle)
|
|
|
|
|
return ds;
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/**
|
|
|
|
|
* find_dock_dependent_device - get a device dependent on this dock
|
|
|
|
|
* @ds: the dock station
|
2014-02-21 08:10:09 +08:00
|
|
|
* @adev: ACPI device object to find.
|
2006-07-10 05:22:28 +08:00
|
|
|
*
|
|
|
|
|
* iterate over the dependent device list for this dock. If the
|
|
|
|
|
* dependent device matches the handle, return.
|
|
|
|
|
*/
|
|
|
|
|
static struct dock_dependent_device *
|
2014-02-21 08:10:09 +08:00
|
|
|
find_dock_dependent_device(struct dock_station *ds, struct acpi_device *adev)
|
2006-07-10 05:22:28 +08:00
|
|
|
{
|
|
|
|
|
struct dock_dependent_device *dd;
|
|
|
|
|
|
2013-06-29 00:24:35 +08:00
|
|
|
list_for_each_entry(dd, &ds->dependent_devices, list)
|
2014-02-21 08:10:09 +08:00
|
|
|
if (adev == dd->adev)
|
2006-07-10 05:22:28 +08:00
|
|
|
return dd;
|
2013-06-29 00:24:35 +08:00
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
void register_dock_dependent_device(struct acpi_device *adev,
|
|
|
|
|
acpi_handle dshandle)
|
2008-08-28 10:03:58 +08:00
|
|
|
{
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
struct dock_station *ds = find_dock_station(dshandle);
|
2008-08-28 10:03:58 +08:00
|
|
|
|
2014-02-21 08:10:09 +08:00
|
|
|
if (ds && !find_dock_dependent_device(ds, adev))
|
|
|
|
|
add_dock_dependent_device(ds, adev);
|
2008-08-28 10:03:58 +08:00
|
|
|
}
|
|
|
|
|
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
/*****************************************************************************
|
|
|
|
|
* Dock functions *
|
|
|
|
|
*****************************************************************************/
|
2008-08-28 10:03:58 +08:00
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/**
|
|
|
|
|
* is_dock_device - see if a device is on a dock station
|
2014-02-21 08:10:09 +08:00
|
|
|
* @adev: ACPI device object to check.
|
2006-07-10 05:22:28 +08:00
|
|
|
*
|
|
|
|
|
* If this device is either the dock station itself,
|
|
|
|
|
* or is a device dependent on the dock station, then it
|
|
|
|
|
* is a dock device
|
|
|
|
|
*/
|
2014-02-21 08:10:09 +08:00
|
|
|
int is_dock_device(struct acpi_device *adev)
|
2006-07-10 05:22:28 +08:00
|
|
|
{
|
2008-08-28 10:03:58 +08:00
|
|
|
struct dock_station *dock_station;
|
|
|
|
|
|
|
|
|
|
if (!dock_station_count)
|
2006-07-10 05:22:28 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2014-02-21 08:10:09 +08:00
|
|
|
if (acpi_dock_match(adev->handle))
|
2006-07-10 05:22:28 +08:00
|
|
|
return 1;
|
2009-10-20 05:14:50 +08:00
|
|
|
|
|
|
|
|
list_for_each_entry(dock_station, &dock_stations, sibling)
|
2014-02-21 08:10:09 +08:00
|
|
|
if (find_dock_dependent_device(dock_station, adev))
|
2008-08-28 10:03:58 +08:00
|
|
|
return 1;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL_GPL(is_dock_device);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* dock_present - see if the dock station is present.
|
|
|
|
|
* @ds: the dock station
|
|
|
|
|
*
|
|
|
|
|
* execute the _STA method. note that present does not
|
|
|
|
|
* imply that we are docked.
|
|
|
|
|
*/
|
|
|
|
|
static int dock_present(struct dock_station *ds)
|
|
|
|
|
{
|
2008-10-10 14:22:59 +08:00
|
|
|
unsigned long long sta;
|
2006-07-10 05:22:28 +08:00
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
|
|
if (ds) {
|
|
|
|
|
status = acpi_evaluate_integer(ds->handle, "_STA", NULL, &sta);
|
|
|
|
|
if (ACPI_SUCCESS(status) && sta)
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2013-07-01 05:46:42 +08:00
|
|
|
* hot_remove_dock_devices - Remove dock station devices.
|
|
|
|
|
* @ds: Dock station.
|
|
|
|
|
*/
|
|
|
|
|
static void hot_remove_dock_devices(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
struct dock_dependent_device *dd;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Walk the list in reverse order so that devices that have been added
|
|
|
|
|
* last are removed first (in case there are some indirect dependencies
|
|
|
|
|
* between them).
|
|
|
|
|
*/
|
|
|
|
|
list_for_each_entry_reverse(dd, &ds->dependent_devices, list)
|
2020-10-27 05:48:34 +08:00
|
|
|
dock_hotplug_event(dd, ACPI_NOTIFY_EJECT_REQUEST,
|
|
|
|
|
DOCK_CALL_HANDLER);
|
2013-07-01 05:46:42 +08:00
|
|
|
|
|
|
|
|
list_for_each_entry_reverse(dd, &ds->dependent_devices, list)
|
2014-02-21 08:10:09 +08:00
|
|
|
acpi_bus_trim(dd->adev);
|
2013-07-01 05:46:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* hotplug_dock_devices - Insert devices on a dock station.
|
2006-07-10 05:22:28 +08:00
|
|
|
* @ds: the dock station
|
2013-07-01 05:46:42 +08:00
|
|
|
* @event: either bus check or device check request
|
2006-07-10 05:22:28 +08:00
|
|
|
*
|
|
|
|
|
* Some devices on the dock station need to have drivers called
|
|
|
|
|
* to perform hotplug operations after a dock event has occurred.
|
|
|
|
|
* Traverse the list of dock devices that have registered a
|
|
|
|
|
* hotplug handler, and call the handler.
|
|
|
|
|
*/
|
|
|
|
|
static void hotplug_dock_devices(struct dock_station *ds, u32 event)
|
|
|
|
|
{
|
|
|
|
|
struct dock_dependent_device *dd;
|
|
|
|
|
|
2013-07-05 09:03:25 +08:00
|
|
|
/* Call driver specific post-dock fixups. */
|
|
|
|
|
list_for_each_entry(dd, &ds->dependent_devices, list)
|
|
|
|
|
dock_hotplug_event(dd, event, DOCK_CALL_FIXUP);
|
|
|
|
|
|
2013-07-01 05:46:42 +08:00
|
|
|
/* Call driver specific hotplug functions. */
|
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 17:22:53 +08:00
|
|
|
list_for_each_entry(dd, &ds->dependent_devices, list)
|
2013-07-05 09:03:25 +08:00
|
|
|
dock_hotplug_event(dd, event, DOCK_CALL_HANDLER);
|
2006-07-10 05:22:28 +08:00
|
|
|
|
|
|
|
|
/*
|
2014-02-21 08:10:09 +08:00
|
|
|
* Check if all devices have been enumerated already. If not, run
|
|
|
|
|
* acpi_bus_scan() for them and that will cause scan handlers to be
|
|
|
|
|
* attached to device objects or acpi_drivers to be stopped/started if
|
|
|
|
|
* they are present.
|
2006-07-10 05:22:28 +08:00
|
|
|
*/
|
2014-02-21 08:10:09 +08:00
|
|
|
list_for_each_entry(dd, &ds->dependent_devices, list) {
|
|
|
|
|
struct acpi_device *adev = dd->adev;
|
|
|
|
|
|
|
|
|
|
if (!acpi_device_enumerated(adev)) {
|
|
|
|
|
int ret = acpi_bus_scan(adev->handle);
|
|
|
|
|
if (ret)
|
|
|
|
|
dev_dbg(&adev->dev, "scan error %d\n", -ret);
|
|
|
|
|
}
|
|
|
|
|
}
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void dock_event(struct dock_station *ds, u32 event, int num)
|
|
|
|
|
{
|
2008-08-28 10:03:58 +08:00
|
|
|
struct device *dev = &ds->dock_device->dev;
|
2007-08-11 04:10:32 +08:00
|
|
|
char event_string[13];
|
2007-05-10 06:10:22 +08:00
|
|
|
char *envp[] = { event_string, NULL };
|
2008-08-28 10:06:16 +08:00
|
|
|
struct dock_dependent_device *dd;
|
2007-05-10 06:10:22 +08:00
|
|
|
|
|
|
|
|
if (num == UNDOCK_EVENT)
|
2007-08-11 04:10:32 +08:00
|
|
|
sprintf(event_string, "EVENT=undock");
|
2007-05-10 06:10:22 +08:00
|
|
|
else
|
2007-08-11 04:10:32 +08:00
|
|
|
sprintf(event_string, "EVENT=dock");
|
2007-05-10 06:10:22 +08:00
|
|
|
|
2006-08-02 05:59:19 +08:00
|
|
|
/*
|
2006-12-12 04:05:08 +08:00
|
|
|
* Indicate that the status of the dock station has
|
|
|
|
|
* changed.
|
2006-08-02 05:59:19 +08:00
|
|
|
*/
|
2008-08-28 10:06:16 +08:00
|
|
|
if (num == DOCK_EVENT)
|
|
|
|
|
kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);
|
|
|
|
|
|
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 17:22:53 +08:00
|
|
|
list_for_each_entry(dd, &ds->dependent_devices, list)
|
2013-07-05 09:03:25 +08:00
|
|
|
dock_hotplug_event(dd, event, DOCK_CALL_UEVENT);
|
2009-10-20 05:14:50 +08:00
|
|
|
|
2008-08-28 10:06:16 +08:00
|
|
|
if (num != DOCK_EVENT)
|
|
|
|
|
kobject_uevent_env(&dev->kobj, KOBJ_CHANGE, envp);
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* handle_dock - handle a dock event
|
|
|
|
|
* @ds: the dock station
|
|
|
|
|
* @dock: to dock, or undock - that is the question
|
|
|
|
|
*
|
|
|
|
|
* Execute the _DCK method in response to an acpi event
|
|
|
|
|
*/
|
|
|
|
|
static void handle_dock(struct dock_station *ds, int dock)
|
|
|
|
|
{
|
|
|
|
|
acpi_status status;
|
|
|
|
|
struct acpi_object_list arg_list;
|
|
|
|
|
union acpi_object arg;
|
2013-09-03 08:32:10 +08:00
|
|
|
unsigned long long value;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
2012-11-21 07:42:30 +08:00
|
|
|
acpi_handle_info(ds->handle, "%s\n", dock ? "docking" : "undocking");
|
2006-07-10 05:22:28 +08:00
|
|
|
|
|
|
|
|
/* _DCK method has one argument */
|
|
|
|
|
arg_list.count = 1;
|
|
|
|
|
arg_list.pointer = &arg;
|
|
|
|
|
arg.type = ACPI_TYPE_INTEGER;
|
|
|
|
|
arg.integer.value = dock;
|
2013-09-03 08:32:10 +08:00
|
|
|
status = acpi_evaluate_integer(ds->handle, "_DCK", &arg_list, &value);
|
2008-08-28 10:03:58 +08:00
|
|
|
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
|
2012-11-21 07:42:30 +08:00
|
|
|
acpi_handle_err(ds->handle, "Failed to execute _DCK (0x%x)\n",
|
|
|
|
|
status);
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void dock(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
handle_dock(ds, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void undock(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
handle_dock(ds, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void begin_dock(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
ds->flags |= DOCK_DOCKING;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void complete_dock(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
ds->flags &= ~(DOCK_DOCKING);
|
|
|
|
|
ds->last_dock_time = jiffies;
|
|
|
|
|
}
|
|
|
|
|
|
2007-05-10 06:08:15 +08:00
|
|
|
static inline void begin_undock(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
ds->flags |= DOCK_UNDOCKING;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void complete_undock(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
ds->flags &= ~(DOCK_UNDOCKING);
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/**
|
|
|
|
|
* dock_in_progress - see if we are in the middle of handling a dock event
|
|
|
|
|
* @ds: the dock station
|
|
|
|
|
*
|
|
|
|
|
* Sometimes while docking, false dock events can be sent to the driver
|
|
|
|
|
* because good connections aren't made or some other reason. Ignore these
|
|
|
|
|
* if we are in the middle of doing something.
|
|
|
|
|
*/
|
|
|
|
|
static int dock_in_progress(struct dock_station *ds)
|
|
|
|
|
{
|
|
|
|
|
if ((ds->flags & DOCK_DOCKING) ||
|
|
|
|
|
time_before(jiffies, (ds->last_dock_time + HZ)))
|
|
|
|
|
return 1;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-12-05 06:49:58 +08:00
|
|
|
/**
|
|
|
|
|
* handle_eject_request - handle an undock request checking for error conditions
|
|
|
|
|
*
|
|
|
|
|
* Check to make sure the dock device is still present, then undock and
|
|
|
|
|
* hotremove all the devices that may need removing.
|
|
|
|
|
*/
|
|
|
|
|
static int handle_eject_request(struct dock_station *ds, u32 event)
|
|
|
|
|
{
|
|
|
|
|
if (dock_in_progress(ds))
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* here we need to generate the undock
|
|
|
|
|
* event prior to actually doing the undock
|
|
|
|
|
* so that the device struct still exists.
|
2008-08-06 23:56:01 +08:00
|
|
|
* Also, even send the dock event if the
|
|
|
|
|
* device is not present anymore
|
2006-12-05 06:49:58 +08:00
|
|
|
*/
|
|
|
|
|
dock_event(ds, event, UNDOCK_EVENT);
|
2008-08-06 23:56:01 +08:00
|
|
|
|
2013-07-01 05:46:42 +08:00
|
|
|
hot_remove_dock_devices(ds);
|
2006-12-05 06:49:58 +08:00
|
|
|
undock(ds);
|
2013-06-29 00:24:42 +08:00
|
|
|
acpi_evaluate_lck(ds->handle, 0);
|
|
|
|
|
acpi_evaluate_ej0(ds->handle);
|
2006-12-05 06:49:58 +08:00
|
|
|
if (dock_present(ds)) {
|
2012-11-21 07:42:30 +08:00
|
|
|
acpi_handle_err(ds->handle, "Unable to undock!\n");
|
2006-12-05 06:49:58 +08:00
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
2007-05-10 06:08:15 +08:00
|
|
|
complete_undock(ds);
|
2006-12-05 06:49:58 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/**
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
* dock_notify - Handle ACPI dock notification.
|
|
|
|
|
* @adev: Dock station's ACPI device object.
|
|
|
|
|
* @event: Event code.
|
2006-07-10 05:22:28 +08:00
|
|
|
*
|
|
|
|
|
* If we are notified to dock, then check to see if the dock is
|
|
|
|
|
* present and then dock. Notify all drivers of the dock event,
|
2006-12-05 06:49:58 +08:00
|
|
|
* and then hotplug and devices that may need hotplugging.
|
2006-07-10 05:22:28 +08:00
|
|
|
*/
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
int dock_notify(struct acpi_device *adev, u32 event)
|
2006-07-10 05:22:28 +08:00
|
|
|
{
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
acpi_handle handle = adev->handle;
|
|
|
|
|
struct dock_station *ds = find_dock_station(handle);
|
2008-08-28 10:03:58 +08:00
|
|
|
int surprise_removal = 0;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
if (!ds)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
2008-08-28 10:03:58 +08:00
|
|
|
/*
|
|
|
|
|
* According to acpi spec 3.0a, if a DEVICE_CHECK notification
|
|
|
|
|
* is sent and _DCK is present, it is assumed to mean an undock
|
|
|
|
|
* request.
|
|
|
|
|
*/
|
|
|
|
|
if ((ds->flags & DOCK_IS_DOCK) && event == ACPI_NOTIFY_DEVICE_CHECK)
|
|
|
|
|
event = ACPI_NOTIFY_EJECT_REQUEST;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* dock station: BUS_CHECK - docked or surprise removal
|
|
|
|
|
* DEVICE_CHECK - undocked
|
|
|
|
|
* other device: BUS_CHECK/DEVICE_CHECK - added or surprise removal
|
|
|
|
|
*
|
|
|
|
|
* To simplify event handling, dock dependent device handler always
|
|
|
|
|
* get ACPI_NOTIFY_BUS_CHECK/ACPI_NOTIFY_DEVICE_CHECK for add and
|
|
|
|
|
* ACPI_NOTIFY_EJECT_REQUEST for removal
|
|
|
|
|
*/
|
2006-07-10 05:22:28 +08:00
|
|
|
switch (event) {
|
|
|
|
|
case ACPI_NOTIFY_BUS_CHECK:
|
2008-08-28 10:03:58 +08:00
|
|
|
case ACPI_NOTIFY_DEVICE_CHECK:
|
2014-02-10 20:44:20 +08:00
|
|
|
if (!dock_in_progress(ds) && !acpi_device_enumerated(adev)) {
|
2006-07-10 05:22:28 +08:00
|
|
|
begin_dock(ds);
|
|
|
|
|
dock(ds);
|
|
|
|
|
if (!dock_present(ds)) {
|
2012-11-21 07:42:30 +08:00
|
|
|
acpi_handle_err(handle, "Unable to dock!\n");
|
2008-08-28 10:02:03 +08:00
|
|
|
complete_dock(ds);
|
2006-07-10 05:22:28 +08:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
hotplug_dock_devices(ds, event);
|
|
|
|
|
complete_dock(ds);
|
|
|
|
|
dock_event(ds, event, DOCK_EVENT);
|
2013-06-29 00:24:42 +08:00
|
|
|
acpi_evaluate_lck(ds->handle, 1);
|
2010-12-13 13:36:15 +08:00
|
|
|
acpi_update_all_gpes();
|
2008-08-28 10:03:58 +08:00
|
|
|
break;
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
2008-08-28 10:03:58 +08:00
|
|
|
if (dock_present(ds) || dock_in_progress(ds))
|
|
|
|
|
break;
|
|
|
|
|
/* This is a surprise removal */
|
|
|
|
|
surprise_removal = 1;
|
|
|
|
|
event = ACPI_NOTIFY_EJECT_REQUEST;
|
|
|
|
|
/* Fall back */
|
2020-07-08 04:09:37 +08:00
|
|
|
fallthrough;
|
2006-07-10 05:22:28 +08:00
|
|
|
case ACPI_NOTIFY_EJECT_REQUEST:
|
2007-05-10 06:08:15 +08:00
|
|
|
begin_undock(ds);
|
2008-08-28 10:05:45 +08:00
|
|
|
if ((immediate_undock && !(ds->flags & DOCK_IS_ATA))
|
|
|
|
|
|| surprise_removal)
|
2007-05-10 06:08:15 +08:00
|
|
|
handle_eject_request(ds, event);
|
|
|
|
|
else
|
|
|
|
|
dock_event(ds, event, UNDOCK_EVENT);
|
2006-07-10 05:22:28 +08:00
|
|
|
break;
|
|
|
|
|
}
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
return 0;
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
|
|
|
|
|
2006-12-05 06:49:58 +08:00
|
|
|
/*
|
|
|
|
|
* show_docked - read method for "docked" file in sysfs
|
|
|
|
|
*/
|
2020-12-17 20:45:36 +08:00
|
|
|
static ssize_t docked_show(struct device *dev,
|
2006-12-05 06:49:58 +08:00
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
|
{
|
2009-10-20 05:14:45 +08:00
|
|
|
struct dock_station *dock_station = dev->platform_data;
|
2014-02-15 08:29:06 +08:00
|
|
|
struct acpi_device *adev = NULL;
|
2006-12-05 06:49:58 +08:00
|
|
|
|
2014-02-15 08:29:06 +08:00
|
|
|
acpi_bus_get_device(dock_station->handle, &adev);
|
|
|
|
|
return snprintf(buf, PAGE_SIZE, "%u\n", acpi_device_enumerated(adev));
|
2006-12-05 06:49:58 +08:00
|
|
|
}
|
2020-12-17 20:45:36 +08:00
|
|
|
static DEVICE_ATTR_RO(docked);
|
2006-12-05 06:49:58 +08:00
|
|
|
|
2007-05-10 06:08:15 +08:00
|
|
|
/*
|
|
|
|
|
* show_flags - read method for flags file in sysfs
|
|
|
|
|
*/
|
2020-12-17 20:45:36 +08:00
|
|
|
static ssize_t flags_show(struct device *dev,
|
2007-05-10 06:08:15 +08:00
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
|
{
|
2009-10-20 05:14:45 +08:00
|
|
|
struct dock_station *dock_station = dev->platform_data;
|
2007-05-10 06:08:15 +08:00
|
|
|
return snprintf(buf, PAGE_SIZE, "%d\n", dock_station->flags);
|
|
|
|
|
|
|
|
|
|
}
|
2020-12-17 20:45:36 +08:00
|
|
|
static DEVICE_ATTR_RO(flags);
|
2007-05-10 06:08:15 +08:00
|
|
|
|
2006-12-05 06:49:58 +08:00
|
|
|
/*
|
|
|
|
|
* write_undock - write method for "undock" file in sysfs
|
|
|
|
|
*/
|
2020-12-17 20:45:36 +08:00
|
|
|
static ssize_t undock_store(struct device *dev, struct device_attribute *attr,
|
|
|
|
|
const char *buf, size_t count)
|
2006-12-05 06:49:58 +08:00
|
|
|
{
|
|
|
|
|
int ret;
|
2009-10-20 05:14:45 +08:00
|
|
|
struct dock_station *dock_station = dev->platform_data;
|
2006-12-05 06:49:58 +08:00
|
|
|
|
|
|
|
|
if (!count)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2013-06-16 06:38:30 +08:00
|
|
|
acpi_scan_lock_acquire();
|
2008-03-12 08:07:27 +08:00
|
|
|
begin_undock(dock_station);
|
2006-12-05 06:49:58 +08:00
|
|
|
ret = handle_eject_request(dock_station, ACPI_NOTIFY_EJECT_REQUEST);
|
2013-06-16 06:38:30 +08:00
|
|
|
acpi_scan_lock_release();
|
2006-12-05 06:49:58 +08:00
|
|
|
return ret ? ret: count;
|
|
|
|
|
}
|
2020-12-17 20:45:36 +08:00
|
|
|
static DEVICE_ATTR_WO(undock);
|
2006-12-05 06:49:58 +08:00
|
|
|
|
2007-02-20 07:19:31 +08:00
|
|
|
/*
|
|
|
|
|
* show_dock_uid - read method for "uid" file in sysfs
|
|
|
|
|
*/
|
2020-12-17 20:45:36 +08:00
|
|
|
static ssize_t uid_show(struct device *dev,
|
|
|
|
|
struct device_attribute *attr, char *buf)
|
2007-02-20 07:19:31 +08:00
|
|
|
{
|
2008-10-10 14:22:59 +08:00
|
|
|
unsigned long long lbuf;
|
2009-10-20 05:14:45 +08:00
|
|
|
struct dock_station *dock_station = dev->platform_data;
|
2007-05-10 06:04:24 +08:00
|
|
|
acpi_status status = acpi_evaluate_integer(dock_station->handle,
|
|
|
|
|
"_UID", NULL, &lbuf);
|
|
|
|
|
if (ACPI_FAILURE(status))
|
2007-02-20 07:19:31 +08:00
|
|
|
return 0;
|
2007-05-10 06:04:24 +08:00
|
|
|
|
2008-10-10 14:22:59 +08:00
|
|
|
return snprintf(buf, PAGE_SIZE, "%llx\n", lbuf);
|
2007-02-20 07:19:31 +08:00
|
|
|
}
|
2020-12-17 20:45:36 +08:00
|
|
|
static DEVICE_ATTR_RO(uid);
|
2007-02-20 07:19:31 +08:00
|
|
|
|
2020-12-17 20:45:36 +08:00
|
|
|
static ssize_t type_show(struct device *dev,
|
|
|
|
|
struct device_attribute *attr, char *buf)
|
2008-08-28 10:07:45 +08:00
|
|
|
{
|
2009-10-20 05:14:45 +08:00
|
|
|
struct dock_station *dock_station = dev->platform_data;
|
2008-08-28 10:07:45 +08:00
|
|
|
char *type;
|
|
|
|
|
|
|
|
|
|
if (dock_station->flags & DOCK_IS_DOCK)
|
|
|
|
|
type = "dock_station";
|
|
|
|
|
else if (dock_station->flags & DOCK_IS_ATA)
|
|
|
|
|
type = "ata_bay";
|
|
|
|
|
else if (dock_station->flags & DOCK_IS_BAT)
|
|
|
|
|
type = "battery_bay";
|
|
|
|
|
else
|
|
|
|
|
type = "unknown";
|
|
|
|
|
|
|
|
|
|
return snprintf(buf, PAGE_SIZE, "%s\n", type);
|
|
|
|
|
}
|
2020-12-17 20:45:36 +08:00
|
|
|
static DEVICE_ATTR_RO(type);
|
2008-08-28 10:07:45 +08:00
|
|
|
|
2009-10-20 05:14:24 +08:00
|
|
|
static struct attribute *dock_attributes[] = {
|
|
|
|
|
&dev_attr_docked.attr,
|
|
|
|
|
&dev_attr_flags.attr,
|
|
|
|
|
&dev_attr_undock.attr,
|
|
|
|
|
&dev_attr_uid.attr,
|
|
|
|
|
&dev_attr_type.attr,
|
|
|
|
|
NULL
|
|
|
|
|
};
|
|
|
|
|
|
2017-08-02 08:28:46 +08:00
|
|
|
static const struct attribute_group dock_attribute_group = {
|
2009-10-20 05:14:24 +08:00
|
|
|
.attrs = dock_attributes
|
|
|
|
|
};
|
|
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/**
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
* acpi_dock_add - Add a new dock station
|
|
|
|
|
* @adev: Dock station ACPI device object.
|
2006-07-10 05:22:28 +08:00
|
|
|
*
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
* allocated and initialize a new dock station device.
|
2006-07-10 05:22:28 +08:00
|
|
|
*/
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
void acpi_dock_add(struct acpi_device *adev)
|
2006-07-10 05:22:28 +08:00
|
|
|
{
|
2013-07-05 09:23:36 +08:00
|
|
|
struct dock_station *dock_station, ds = { NULL, };
|
2014-02-16 07:09:47 +08:00
|
|
|
struct platform_device_info pdevinfo;
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
acpi_handle handle = adev->handle;
|
2009-10-20 05:14:50 +08:00
|
|
|
struct platform_device *dd;
|
2013-07-05 09:23:36 +08:00
|
|
|
int ret;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
2014-02-16 07:09:47 +08:00
|
|
|
memset(&pdevinfo, 0, sizeof(pdevinfo));
|
|
|
|
|
pdevinfo.name = "dock";
|
|
|
|
|
pdevinfo.id = dock_station_count;
|
2015-03-17 06:49:03 +08:00
|
|
|
pdevinfo.fwnode = acpi_fwnode_handle(adev);
|
2014-02-16 07:09:47 +08:00
|
|
|
pdevinfo.data = &ds;
|
|
|
|
|
pdevinfo.size_data = sizeof(ds);
|
|
|
|
|
dd = platform_device_register_full(&pdevinfo);
|
2009-10-20 05:14:50 +08:00
|
|
|
if (IS_ERR(dd))
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
return;
|
2009-10-20 05:14:50 +08:00
|
|
|
|
|
|
|
|
dock_station = dd->dev.platform_data;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
|
|
|
|
dock_station->handle = handle;
|
2009-10-20 05:14:50 +08:00
|
|
|
dock_station->dock_device = dd;
|
2006-07-10 05:22:28 +08:00
|
|
|
dock_station->last_dock_time = jiffies - HZ;
|
2009-10-20 05:14:50 +08:00
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&dock_station->sibling);
|
|
|
|
|
INIT_LIST_HEAD(&dock_station->dependent_devices);
|
2007-05-10 06:08:15 +08:00
|
|
|
|
2007-05-10 06:09:12 +08:00
|
|
|
/* we want the dock device to send uevents */
|
2009-10-20 05:14:50 +08:00
|
|
|
dev_set_uevent_suppress(&dd->dev, 0);
|
2007-05-10 06:09:12 +08:00
|
|
|
|
2013-06-29 00:24:42 +08:00
|
|
|
if (acpi_dock_match(handle))
|
2008-08-28 10:03:58 +08:00
|
|
|
dock_station->flags |= DOCK_IS_DOCK;
|
2013-06-29 00:24:42 +08:00
|
|
|
if (acpi_ata_match(handle))
|
2008-08-28 10:03:58 +08:00
|
|
|
dock_station->flags |= DOCK_IS_ATA;
|
2014-02-16 07:09:34 +08:00
|
|
|
if (acpi_device_is_battery(adev))
|
2008-08-28 10:03:58 +08:00
|
|
|
dock_station->flags |= DOCK_IS_BAT;
|
|
|
|
|
|
2009-10-20 05:14:50 +08:00
|
|
|
ret = sysfs_create_group(&dd->dev.kobj, &dock_attribute_group);
|
2008-08-28 10:07:45 +08:00
|
|
|
if (ret)
|
2009-10-20 05:14:24 +08:00
|
|
|
goto err_unregister;
|
2006-12-05 06:49:43 +08:00
|
|
|
|
2006-07-10 05:22:28 +08:00
|
|
|
/* add the dock station as a device dependent on itself */
|
2014-02-21 08:10:09 +08:00
|
|
|
ret = add_dock_dependent_device(dock_station, adev);
|
2009-10-20 05:14:29 +08:00
|
|
|
if (ret)
|
2009-10-20 05:14:24 +08:00
|
|
|
goto err_rmgroup;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
2008-08-28 10:03:58 +08:00
|
|
|
dock_station_count++;
|
2009-10-02 01:59:23 +08:00
|
|
|
list_add(&dock_station->sibling, &dock_stations);
|
ACPI / dock: Dispatch dock notifications from the global notify handler
The ACPI dock station code carries out an extra namespace scan
before the main one in order to find and register all of the dock
device objects. Then, it registers a notify handler for each of
them for handling dock events.
However, dock device objects need not be scanned for upfront. They
very well can be enumerated and registered during the first phase
of the main namespace scan, before attaching scan handlers and ACPI
drivers to ACPI device objects. Then, the dependent devices can be
added to the in the second phase. That makes it possible to drop
the extra namespace scan, so do it.
Moreover, it is not necessary to register notify handlers for all
of the dock stations' namespace nodes, becuase notifications may
be dispatched from the global notify handler for them. Do that and
drop two functions used for dock notify handling, acpi_dock_deferred_cb()
and dock_notify_handler(), that aren't necessary any more.
Finally, some dock station objects have _HID objects matching the
ACPI container scan handler which causes it to claim those objects
and try to handle their hotplug, but that is not a good idea,
because those objects have their own special hotplug handling anyway.
For this reason, the hotplug_notify flag should not be set for ACPI
device objects representing dock stations and the container scan
handler should be made ignore those objects, so make that happen.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-16 08:51:01 +08:00
|
|
|
adev->flags.is_dock_station = true;
|
|
|
|
|
dev_info(&adev->dev, "ACPI dock station (docks/bays count: %d)\n",
|
|
|
|
|
dock_station_count);
|
|
|
|
|
return;
|
2006-07-10 05:22:28 +08:00
|
|
|
|
2009-10-20 05:14:24 +08:00
|
|
|
err_rmgroup:
|
2009-10-20 05:14:50 +08:00
|
|
|
sysfs_remove_group(&dd->dev.kobj, &dock_attribute_group);
|
2014-02-21 08:11:38 +08:00
|
|
|
|
2009-10-20 05:14:24 +08:00
|
|
|
err_unregister:
|
2009-10-20 05:14:50 +08:00
|
|
|
platform_device_unregister(dd);
|
2012-11-21 07:42:30 +08:00
|
|
|
acpi_handle_err(handle, "%s encountered error %d\n", __func__, ret);
|
2006-07-10 05:22:28 +08:00
|
|
|
}
|
