2017-11-08 00:30:07 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2005-03-22 02:52:54 +08:00
|
|
|
/*
|
2008-01-25 14:50:12 +08:00
|
|
|
* drivers/base/dd.c - The core device/driver interactions.
|
2005-03-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* This file contains the (sometimes tricky) code that controls the
|
|
|
|
* interactions between devices and drivers, which primarily includes
|
|
|
|
* driver binding and unbinding.
|
2005-03-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* All of this code used to exist in drivers/base/bus.c, but was
|
|
|
|
* relocated to here in the name of compartmentalization (since it wasn't
|
|
|
|
* strictly code just for the 'struct bus_type'.
|
2005-03-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Copyright (c) 2002-5 Patrick Mochel
|
|
|
|
* Copyright (c) 2002-3 Open Source Development Labs
|
2009-05-12 05:16:57 +08:00
|
|
|
* Copyright (c) 2007-2009 Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
* Copyright (c) 2007-2009 Novell Inc.
|
2005-03-22 02:52:54 +08:00
|
|
|
*/
|
|
|
|
|
2018-07-08 21:34:59 +08:00
|
|
|
#include <linux/debugfs.h>
|
2005-03-22 02:52:54 +08:00
|
|
|
#include <linux/device.h>
|
2009-02-14 08:59:06 +08:00
|
|
|
#include <linux/delay.h>
|
2017-04-10 19:21:01 +08:00
|
|
|
#include <linux/dma-mapping.h>
|
2017-07-26 07:31:59 +08:00
|
|
|
#include <linux/init.h>
|
2005-03-22 02:52:54 +08:00
|
|
|
#include <linux/module.h>
|
2006-07-19 01:59:59 +08:00
|
|
|
#include <linux/kthread.h>
|
2006-10-28 02:42:37 +08:00
|
|
|
#include <linux/wait.h>
|
2009-02-14 08:59:06 +08:00
|
|
|
#include <linux/async.h>
|
2009-08-19 05:38:32 +08:00
|
|
|
#include <linux/pm_runtime.h>
|
drivers/pinctrl: grab default handles from device core
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-23 01:56:14 +08:00
|
|
|
#include <linux/pinctrl/devinfo.h>
|
2005-03-22 02:52:54 +08:00
|
|
|
|
|
|
|
#include "base.h"
|
|
|
|
#include "power/power.h"
|
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
/*
|
|
|
|
* Deferred Probe infrastructure.
|
|
|
|
*
|
|
|
|
* Sometimes driver probe order matters, but the kernel doesn't always have
|
|
|
|
* dependency information which means some drivers will get probed before a
|
|
|
|
* resource it depends on is available. For example, an SDHCI driver may
|
|
|
|
* first need a GPIO line from an i2c GPIO controller before it can be
|
|
|
|
* initialized. If a required resource is not available yet, a driver can
|
|
|
|
* request probing to be deferred by returning -EPROBE_DEFER from its probe hook
|
|
|
|
*
|
|
|
|
* Deferred probe maintains two lists of devices, a pending list and an active
|
|
|
|
* list. A driver returning -EPROBE_DEFER causes the device to be added to the
|
|
|
|
* pending list. A successful driver probe will trigger moving all devices
|
|
|
|
* from the pending to the active list so that the workqueue will eventually
|
|
|
|
* retry them.
|
|
|
|
*
|
|
|
|
* The deferred_probe_mutex must be held any time the deferred_probe_*_list
|
2012-03-09 04:17:22 +08:00
|
|
|
* of the (struct device*)->p->deferred_probe pointers are manipulated
|
2012-03-05 23:47:41 +08:00
|
|
|
*/
|
|
|
|
static DEFINE_MUTEX(deferred_probe_mutex);
|
|
|
|
static LIST_HEAD(deferred_probe_pending_list);
|
|
|
|
static LIST_HEAD(deferred_probe_active_list);
|
2014-04-29 19:05:22 +08:00
|
|
|
static atomic_t deferred_trigger_count = ATOMIC_INIT(0);
|
2018-07-08 21:34:59 +08:00
|
|
|
static struct dentry *deferred_devices;
|
2018-07-09 23:41:48 +08:00
|
|
|
static bool initcalls_done;
|
2012-03-05 23:47:41 +08:00
|
|
|
|
2015-11-10 17:42:34 +08:00
|
|
|
/*
|
|
|
|
* In some cases, like suspend to RAM or hibernation, It might be reasonable
|
|
|
|
* to prohibit probing of devices as it could be unsafe.
|
|
|
|
* Once defer_all_probes is true all drivers probes will be forcibly deferred.
|
|
|
|
*/
|
|
|
|
static bool defer_all_probes;
|
|
|
|
|
2014-08-08 21:56:36 +08:00
|
|
|
/*
|
2012-03-05 23:47:41 +08:00
|
|
|
* deferred_probe_work_func() - Retry probing devices in the active list.
|
|
|
|
*/
|
|
|
|
static void deferred_probe_work_func(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct device *dev;
|
2012-03-09 04:17:22 +08:00
|
|
|
struct device_private *private;
|
2012-03-05 23:47:41 +08:00
|
|
|
/*
|
|
|
|
* This block processes every device in the deferred 'active' list.
|
|
|
|
* Each device is removed from the active list and passed to
|
|
|
|
* bus_probe_device() to re-attempt the probe. The loop continues
|
|
|
|
* until every device in the active list is removed and retried.
|
|
|
|
*
|
|
|
|
* Note: Once the device is removed from the list and the mutex is
|
|
|
|
* released, it is possible for the device get freed by another thread
|
|
|
|
* and cause a illegal pointer dereference. This code uses
|
|
|
|
* get/put_device() to ensure the device structure cannot disappear
|
|
|
|
* from under our feet.
|
|
|
|
*/
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
while (!list_empty(&deferred_probe_active_list)) {
|
2012-03-09 04:17:22 +08:00
|
|
|
private = list_first_entry(&deferred_probe_active_list,
|
|
|
|
typeof(*dev->p), deferred_probe);
|
|
|
|
dev = private->device;
|
|
|
|
list_del_init(&private->deferred_probe);
|
2012-03-05 23:47:41 +08:00
|
|
|
|
|
|
|
get_device(dev);
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* Drop the mutex while probing each device; the probe path may
|
|
|
|
* manipulate the deferred list
|
|
|
|
*/
|
2012-03-05 23:47:41 +08:00
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
2012-07-05 21:04:44 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Force the device to the end of the dpm_list since
|
|
|
|
* the PM code assumes that the order we add things to
|
|
|
|
* the list is a good order for suspend but deferred
|
|
|
|
* probe makes that very unsafe.
|
|
|
|
*/
|
2018-04-11 07:57:06 +08:00
|
|
|
device_pm_move_to_tail(dev);
|
2012-07-05 21:04:44 +08:00
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Retrying from deferred list\n");
|
2018-06-21 08:35:56 +08:00
|
|
|
bus_probe_device(dev);
|
2012-03-05 23:47:41 +08:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);
|
|
|
|
|
|
|
|
static void driver_deferred_probe_add(struct device *dev)
|
|
|
|
{
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2012-03-09 04:17:22 +08:00
|
|
|
if (list_empty(&dev->p->deferred_probe)) {
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Added to deferred list\n");
|
2012-05-30 09:46:06 +08:00
|
|
|
list_add_tail(&dev->p->deferred_probe, &deferred_probe_pending_list);
|
2012-03-05 23:47:41 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void driver_deferred_probe_del(struct device *dev)
|
|
|
|
{
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2012-03-09 04:17:22 +08:00
|
|
|
if (!list_empty(&dev->p->deferred_probe)) {
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Removed from deferred list\n");
|
2012-03-09 04:17:22 +08:00
|
|
|
list_del_init(&dev->p->deferred_probe);
|
2012-03-05 23:47:41 +08:00
|
|
|
}
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool driver_deferred_probe_enable = false;
|
|
|
|
/**
|
|
|
|
* driver_deferred_probe_trigger() - Kick off re-probing deferred devices
|
|
|
|
*
|
|
|
|
* This functions moves all devices from the pending list to the active
|
|
|
|
* list and schedules the deferred probe workqueue to process them. It
|
|
|
|
* should be called anytime a driver is successfully bound to a device.
|
2014-04-29 19:05:22 +08:00
|
|
|
*
|
|
|
|
* Note, there is a race condition in multi-threaded probe. In the case where
|
|
|
|
* more than one device is probing at the same time, it is possible for one
|
|
|
|
* probe to complete successfully while another is about to defer. If the second
|
|
|
|
* depends on the first, then it will get put on the pending list after the
|
2015-05-26 02:16:11 +08:00
|
|
|
* trigger event has already occurred and will be stuck there.
|
2014-04-29 19:05:22 +08:00
|
|
|
*
|
|
|
|
* The atomic 'deferred_trigger_count' is used to determine if a successful
|
|
|
|
* trigger has occurred in the midst of probing a driver. If the trigger count
|
|
|
|
* changes in the midst of a probe, then deferred processing should be triggered
|
|
|
|
* again.
|
2012-03-05 23:47:41 +08:00
|
|
|
*/
|
|
|
|
static void driver_deferred_probe_trigger(void)
|
|
|
|
{
|
|
|
|
if (!driver_deferred_probe_enable)
|
|
|
|
return;
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* A successful probe means that all the devices in the pending list
|
2012-03-05 23:47:41 +08:00
|
|
|
* should be triggered to be reprobed. Move all the deferred devices
|
2012-03-09 04:20:37 +08:00
|
|
|
* into the active list so they can be retried by the workqueue
|
|
|
|
*/
|
2012-03-05 23:47:41 +08:00
|
|
|
mutex_lock(&deferred_probe_mutex);
|
2014-04-29 19:05:22 +08:00
|
|
|
atomic_inc(&deferred_trigger_count);
|
2012-03-05 23:47:41 +08:00
|
|
|
list_splice_tail_init(&deferred_probe_pending_list,
|
|
|
|
&deferred_probe_active_list);
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* Kick the re-probe thread. It may already be scheduled, but it is
|
|
|
|
* safe to kick it again.
|
|
|
|
*/
|
2016-08-31 01:15:34 +08:00
|
|
|
schedule_work(&deferred_probe_work);
|
2012-03-05 23:47:41 +08:00
|
|
|
}
|
|
|
|
|
2015-11-10 17:42:34 +08:00
|
|
|
/**
|
2018-11-06 15:41:27 +08:00
|
|
|
* device_block_probing() - Block/defer device's probes
|
2015-11-10 17:42:34 +08:00
|
|
|
*
|
|
|
|
* It will disable probing of devices and defer their probes instead.
|
|
|
|
*/
|
|
|
|
void device_block_probing(void)
|
|
|
|
{
|
|
|
|
defer_all_probes = true;
|
|
|
|
/* sync with probes to avoid races. */
|
|
|
|
wait_for_device_probe();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* device_unblock_probing() - Unblock/enable device's probes
|
|
|
|
*
|
|
|
|
* It will restore normal behavior and trigger re-probing of deferred
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
void device_unblock_probing(void)
|
|
|
|
{
|
|
|
|
defer_all_probes = false;
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
}
|
|
|
|
|
2018-07-08 21:34:59 +08:00
|
|
|
/*
|
|
|
|
* deferred_devs_show() - Show the devices in the deferred probe pending list.
|
|
|
|
*/
|
|
|
|
static int deferred_devs_show(struct seq_file *s, void *data)
|
|
|
|
{
|
|
|
|
struct device_private *curr;
|
|
|
|
|
|
|
|
mutex_lock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
|
|
|
|
seq_printf(s, "%s\n", dev_name(curr->device));
|
|
|
|
|
|
|
|
mutex_unlock(&deferred_probe_mutex);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
DEFINE_SHOW_ATTRIBUTE(deferred_devs);
|
|
|
|
|
2018-07-09 23:41:48 +08:00
|
|
|
static int deferred_probe_timeout = -1;
|
|
|
|
static int __init deferred_probe_timeout_setup(char *str)
|
|
|
|
{
|
2018-10-28 14:39:11 +08:00
|
|
|
int timeout;
|
|
|
|
|
|
|
|
if (!kstrtoint(str, 10, &timeout))
|
|
|
|
deferred_probe_timeout = timeout;
|
2018-07-09 23:41:48 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* driver_deferred_probe_check_state() - Check deferred probe state
|
|
|
|
* @dev: device to check
|
|
|
|
*
|
|
|
|
* Returns -ENODEV if init is done and all built-in drivers have had a chance
|
|
|
|
* to probe (i.e. initcalls are done), -ETIMEDOUT if deferred probe debug
|
|
|
|
* timeout has expired, or -EPROBE_DEFER if none of those conditions are met.
|
|
|
|
*
|
|
|
|
* Drivers or subsystems can opt-in to calling this function instead of directly
|
|
|
|
* returning -EPROBE_DEFER.
|
|
|
|
*/
|
|
|
|
int driver_deferred_probe_check_state(struct device *dev)
|
|
|
|
{
|
|
|
|
if (initcalls_done) {
|
|
|
|
if (!deferred_probe_timeout) {
|
|
|
|
dev_WARN(dev, "deferred probe timeout, ignoring dependency");
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
dev_warn(dev, "ignoring dependency for device, assuming no driver");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
return -EPROBE_DEFER;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void deferred_probe_timeout_work_func(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct device_private *private, *p;
|
|
|
|
|
|
|
|
deferred_probe_timeout = 0;
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
flush_work(&deferred_probe_work);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(private, p, &deferred_probe_pending_list, deferred_probe)
|
|
|
|
dev_info(private->device, "deferred probe pending");
|
|
|
|
}
|
|
|
|
static DECLARE_DELAYED_WORK(deferred_probe_timeout_work, deferred_probe_timeout_work_func);
|
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
/**
|
|
|
|
* deferred_probe_initcall() - Enable probing of deferred devices
|
|
|
|
*
|
|
|
|
* We don't want to get in the way when the bulk of drivers are getting probed.
|
|
|
|
* Instead, this initcall makes sure that deferred probing is delayed until
|
|
|
|
* late_initcall time.
|
|
|
|
*/
|
|
|
|
static int deferred_probe_initcall(void)
|
|
|
|
{
|
2018-07-08 21:34:59 +08:00
|
|
|
deferred_devices = debugfs_create_file("devices_deferred", 0444, NULL,
|
|
|
|
NULL, &deferred_devs_fops);
|
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
driver_deferred_probe_enable = true;
|
|
|
|
driver_deferred_probe_trigger();
|
2013-02-15 02:14:27 +08:00
|
|
|
/* Sort as many dependencies as possible before exiting initcalls */
|
2016-08-31 01:15:34 +08:00
|
|
|
flush_work(&deferred_probe_work);
|
2018-07-09 23:41:48 +08:00
|
|
|
initcalls_done = true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Trigger deferred probe again, this time we won't defer anything
|
|
|
|
* that is optional
|
|
|
|
*/
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
flush_work(&deferred_probe_work);
|
|
|
|
|
|
|
|
if (deferred_probe_timeout > 0) {
|
|
|
|
schedule_delayed_work(&deferred_probe_timeout_work,
|
|
|
|
deferred_probe_timeout * HZ);
|
|
|
|
}
|
2012-03-05 23:47:41 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(deferred_probe_initcall);
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2018-07-08 21:34:59 +08:00
|
|
|
static void __exit deferred_probe_exit(void)
|
|
|
|
{
|
|
|
|
debugfs_remove_recursive(deferred_devices);
|
|
|
|
}
|
|
|
|
__exitcall(deferred_probe_exit);
|
|
|
|
|
2016-01-07 23:46:12 +08:00
|
|
|
/**
|
|
|
|
* device_is_bound() - Check if device is bound to a driver
|
|
|
|
* @dev: device to check
|
|
|
|
*
|
|
|
|
* Returns true if passed device has already finished probing successfully
|
|
|
|
* against a driver.
|
|
|
|
*
|
|
|
|
* This function must be called with the device lock held.
|
|
|
|
*/
|
|
|
|
bool device_is_bound(struct device *dev)
|
|
|
|
{
|
2016-01-12 08:51:44 +08:00
|
|
|
return dev->p && klist_node_attached(&dev->p->knode_driver);
|
2016-01-07 23:46:12 +08:00
|
|
|
}
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
static void driver_bound(struct device *dev)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2016-01-07 23:46:12 +08:00
|
|
|
if (device_is_bound(dev)) {
|
2006-08-15 13:43:20 +08:00
|
|
|
printk(KERN_WARNING "%s: device %s already bound\n",
|
2008-03-05 08:41:05 +08:00
|
|
|
__func__, kobject_name(&dev->kobj));
|
2006-10-08 03:55:55 +08:00
|
|
|
return;
|
2006-08-15 13:43:20 +08:00
|
|
|
}
|
2005-09-22 15:47:11 +08:00
|
|
|
|
2014-04-17 08:12:30 +08:00
|
|
|
pr_debug("driver: '%s': %s: bound to device '%s'\n", dev->driver->name,
|
|
|
|
__func__, dev_name(dev));
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
|
2010-03-07 00:50:14 +08:00
|
|
|
klist_add_tail(&dev->p->knode_driver, &dev->driver->p->klist_devices);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
device_links_driver_bound(dev);
|
2010-03-07 00:50:14 +08:00
|
|
|
|
2016-01-07 23:46:14 +08:00
|
|
|
device_pm_check_callbacks(dev);
|
|
|
|
|
2012-03-09 04:20:37 +08:00
|
|
|
/*
|
|
|
|
* Make sure the device is no longer in one of the deferred lists and
|
|
|
|
* kick off retrying all pending devices
|
|
|
|
*/
|
2012-03-05 23:47:41 +08:00
|
|
|
driver_deferred_probe_del(dev);
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
if (dev->bus)
|
2007-11-02 10:41:16 +08:00
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
BUS_NOTIFY_BOUND_DRIVER, dev);
|
2017-07-20 08:24:30 +08:00
|
|
|
|
|
|
|
kobject_uevent(&dev->kobj, KOBJ_BIND);
|
2006-10-08 03:55:55 +08:00
|
|
|
}
|
|
|
|
|
2018-01-11 16:36:38 +08:00
|
|
|
static ssize_t coredump_store(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count)
|
|
|
|
{
|
|
|
|
device_lock(dev);
|
2018-03-15 17:55:25 +08:00
|
|
|
dev->driver->coredump(dev);
|
2018-01-11 16:36:38 +08:00
|
|
|
device_unlock(dev);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_WO(coredump);
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
static int driver_sysfs_add(struct device *dev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2010-07-23 18:56:18 +08:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_BIND_DRIVER, dev);
|
|
|
|
|
2007-11-29 07:59:15 +08:00
|
|
|
ret = sysfs_create_link(&dev->driver->p->kobj, &dev->kobj,
|
2018-01-11 16:36:38 +08:00
|
|
|
kobject_name(&dev->kobj));
|
|
|
|
if (ret)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
ret = sysfs_create_link(&dev->kobj, &dev->driver->p->kobj,
|
|
|
|
"driver");
|
|
|
|
if (ret)
|
|
|
|
goto rm_dev;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DEV_COREDUMP) || !dev->driver->coredump ||
|
|
|
|
!device_create_file(dev, &dev_attr_coredump))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
sysfs_remove_link(&dev->kobj, "driver");
|
|
|
|
|
|
|
|
rm_dev:
|
|
|
|
sysfs_remove_link(&dev->driver->p->kobj,
|
2005-03-22 02:52:54 +08:00
|
|
|
kobject_name(&dev->kobj));
|
2018-01-11 16:36:38 +08:00
|
|
|
|
|
|
|
fail:
|
2006-08-15 13:43:20 +08:00
|
|
|
return ret;
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
static void driver_sysfs_remove(struct device *dev)
|
|
|
|
{
|
|
|
|
struct device_driver *drv = dev->driver;
|
|
|
|
|
|
|
|
if (drv) {
|
2018-01-11 16:36:38 +08:00
|
|
|
if (drv->coredump)
|
|
|
|
device_remove_file(dev, &dev_attr_coredump);
|
2007-11-29 07:59:15 +08:00
|
|
|
sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
|
2006-10-08 03:55:55 +08:00
|
|
|
sysfs_remove_link(&dev->kobj, "driver");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-01-25 14:50:12 +08:00
|
|
|
* device_bind_driver - bind a driver to one device.
|
|
|
|
* @dev: device.
|
2006-10-08 03:55:55 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Allow manual attachment of a driver to a device.
|
|
|
|
* Caller must have already set @dev->driver.
|
2006-10-08 03:55:55 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Note that this does not modify the bus reference count
|
|
|
|
* nor take the bus's rwsem. Please verify those are accounted
|
|
|
|
* for before calling this. (It is ok to call with no other effort
|
|
|
|
* from a driver's probe() method.)
|
2006-10-08 03:55:55 +08:00
|
|
|
*
|
2010-02-18 02:57:05 +08:00
|
|
|
* This function must be called with the device lock held.
|
2006-10-08 03:55:55 +08:00
|
|
|
*/
|
|
|
|
int device_bind_driver(struct device *dev)
|
|
|
|
{
|
2006-11-27 17:35:12 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = driver_sysfs_add(dev);
|
|
|
|
if (!ret)
|
|
|
|
driver_bound(dev);
|
2015-12-05 05:49:17 +08:00
|
|
|
else if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
|
2006-11-27 17:35:12 +08:00
|
|
|
return ret;
|
2006-10-08 03:55:55 +08:00
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_bind_driver);
|
2006-10-08 03:55:55 +08:00
|
|
|
|
2006-07-19 01:59:59 +08:00
|
|
|
static atomic_t probe_count = ATOMIC_INIT(0);
|
2006-10-28 02:42:37 +08:00
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
|
|
|
|
|
2017-11-02 17:22:53 +08:00
|
|
|
static void driver_deferred_probe_add_trigger(struct device *dev,
|
|
|
|
int local_trigger_count)
|
|
|
|
{
|
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
/* Did a trigger occur while probing? Need to re-trigger if yes */
|
|
|
|
if (local_trigger_count != atomic_read(&deferred_trigger_count))
|
|
|
|
driver_deferred_probe_trigger();
|
|
|
|
}
|
|
|
|
|
2007-02-06 08:15:25 +08:00
|
|
|
static int really_probe(struct device *dev, struct device_driver *drv)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2015-11-10 17:42:34 +08:00
|
|
|
int ret = -EPROBE_DEFER;
|
2014-04-29 19:05:22 +08:00
|
|
|
int local_trigger_count = atomic_read(&deferred_trigger_count);
|
2016-10-12 02:41:02 +08:00
|
|
|
bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) &&
|
|
|
|
!drv->suppress_bind_attrs;
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2015-11-10 17:42:34 +08:00
|
|
|
if (defer_all_probes) {
|
|
|
|
/*
|
|
|
|
* Value of defer_all_probes can be set only by
|
2018-11-06 15:41:27 +08:00
|
|
|
* device_block_probing() which, in turn, will call
|
2015-11-10 17:42:34 +08:00
|
|
|
* wait_for_device_probe() right after that to avoid any races.
|
|
|
|
*/
|
|
|
|
dev_dbg(dev, "Driver %s force probe deferral\n", drv->name);
|
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
ret = device_links_check_suppliers(dev);
|
2017-11-02 17:22:53 +08:00
|
|
|
if (ret == -EPROBE_DEFER)
|
|
|
|
driver_deferred_probe_add_trigger(dev, local_trigger_count);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2006-07-19 01:59:59 +08:00
|
|
|
atomic_inc(&probe_count);
|
2007-11-29 15:49:41 +08:00
|
|
|
pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->bus->name, __func__, drv->name, dev_name(dev));
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
WARN_ON(!list_empty(&dev->devres_head));
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2016-08-11 23:20:58 +08:00
|
|
|
re_probe:
|
2005-03-22 02:52:54 +08:00
|
|
|
dev->driver = drv;
|
drivers/pinctrl: grab default handles from device core
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-23 01:56:14 +08:00
|
|
|
|
|
|
|
/* If using pinctrl, bind pins now before probing */
|
|
|
|
ret = pinctrl_bind_pins(dev);
|
|
|
|
if (ret)
|
2015-12-05 05:49:17 +08:00
|
|
|
goto pinctrl_bind_failed;
|
drivers/pinctrl: grab default handles from device core
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.
A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.
This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:
struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}
The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2
A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.
This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.
ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
<linux/kref.h> so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Mitch Bradley <wmb@firmworks.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Rickard Andersson <rickard.andersson@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2013-01-23 01:56:14 +08:00
|
|
|
|
2018-08-24 15:40:24 +08:00
|
|
|
if (dev->bus->dma_configure) {
|
|
|
|
ret = dev->bus->dma_configure(dev);
|
|
|
|
if (ret)
|
|
|
|
goto dma_failed;
|
|
|
|
}
|
2017-04-10 19:21:01 +08:00
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
if (driver_sysfs_add(dev)) {
|
|
|
|
printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
__func__, dev_name(dev));
|
2006-10-08 03:55:55 +08:00
|
|
|
goto probe_failed;
|
|
|
|
}
|
|
|
|
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 20:59:27 +08:00
|
|
|
if (dev->pm_domain && dev->pm_domain->activate) {
|
|
|
|
ret = dev->pm_domain->activate(dev);
|
|
|
|
if (ret)
|
|
|
|
goto probe_failed;
|
|
|
|
}
|
|
|
|
|
2006-01-05 22:29:51 +08:00
|
|
|
if (dev->bus->probe) {
|
|
|
|
ret = dev->bus->probe(dev);
|
2006-10-08 03:55:55 +08:00
|
|
|
if (ret)
|
2006-07-19 01:59:59 +08:00
|
|
|
goto probe_failed;
|
2006-01-05 22:29:51 +08:00
|
|
|
} else if (drv->probe) {
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
ret = drv->probe(dev);
|
2006-10-08 03:55:55 +08:00
|
|
|
if (ret)
|
2006-07-19 01:59:59 +08:00
|
|
|
goto probe_failed;
|
2006-08-15 13:43:20 +08:00
|
|
|
}
|
2006-10-08 03:55:55 +08:00
|
|
|
|
2016-08-11 23:20:58 +08:00
|
|
|
if (test_remove) {
|
|
|
|
test_remove = false;
|
|
|
|
|
2016-10-12 02:41:03 +08:00
|
|
|
if (dev->bus->remove)
|
2016-08-11 23:20:58 +08:00
|
|
|
dev->bus->remove(dev);
|
|
|
|
else if (drv->remove)
|
|
|
|
drv->remove(dev);
|
|
|
|
|
|
|
|
devres_release_all(dev);
|
|
|
|
driver_sysfs_remove(dev);
|
|
|
|
dev->driver = NULL;
|
|
|
|
dev_set_drvdata(dev, NULL);
|
|
|
|
if (dev->pm_domain && dev->pm_domain->dismiss)
|
|
|
|
dev->pm_domain->dismiss(dev);
|
|
|
|
pm_runtime_reinit(dev);
|
|
|
|
|
|
|
|
goto re_probe;
|
|
|
|
}
|
|
|
|
|
2015-10-21 12:15:06 +08:00
|
|
|
pinctrl_init_done(dev);
|
|
|
|
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 20:59:27 +08:00
|
|
|
if (dev->pm_domain && dev->pm_domain->sync)
|
|
|
|
dev->pm_domain->sync(dev);
|
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
driver_bound(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
ret = 1;
|
2007-11-29 15:49:41 +08:00
|
|
|
pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->bus->name, __func__, dev_name(dev), drv->name);
|
2006-07-19 01:59:59 +08:00
|
|
|
goto done;
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
|
2006-07-19 01:59:59 +08:00
|
|
|
probe_failed:
|
2018-08-24 16:28:18 +08:00
|
|
|
arch_teardown_dma_ops(dev);
|
2017-04-10 19:21:01 +08:00
|
|
|
dma_failed:
|
2015-12-05 05:49:17 +08:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
|
|
|
|
pinctrl_bind_failed:
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
device_links_no_driver(dev);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
devres_release_all(dev);
|
2006-10-08 03:55:55 +08:00
|
|
|
driver_sysfs_remove(dev);
|
|
|
|
dev->driver = NULL;
|
2012-05-23 06:09:34 +08:00
|
|
|
dev_set_drvdata(dev, NULL);
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 20:59:27 +08:00
|
|
|
if (dev->pm_domain && dev->pm_domain->dismiss)
|
|
|
|
dev->pm_domain->dismiss(dev);
|
PM / runtime: Re-init runtime PM states at probe error and driver unbind
There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.
Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.
This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().
Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.
These are two scenarios that suffers from this unmet expectation.
i) A failed ->probe() sequence requests probe deferral:
->probe()
...
pm_runtime_enable()
pm_runtime_get_sync()
...
err:
pm_runtime_put()
pm_runtime_disable()
...
As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.
In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.
ii) A driver re-bind sequence:
At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.
->remove()
...
pm_runtime_put()
pm_runtime_disable()
...
Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.
Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.
Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.
The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.
A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.
This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.
To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.
Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-18 18:48:39 +08:00
|
|
|
pm_runtime_reinit(dev);
|
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.
To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers. Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.
Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.
While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-25 20:12:29 +08:00
|
|
|
dev_pm_set_driver_flags(dev, 0);
|
2006-10-08 03:55:55 +08:00
|
|
|
|
2015-01-18 03:14:41 +08:00
|
|
|
switch (ret) {
|
|
|
|
case -EPROBE_DEFER:
|
2012-03-05 23:47:41 +08:00
|
|
|
/* Driver requested deferred probing */
|
2015-03-10 19:55:49 +08:00
|
|
|
dev_dbg(dev, "Driver %s requests probe deferral\n", drv->name);
|
2017-11-02 17:22:53 +08:00
|
|
|
driver_deferred_probe_add_trigger(dev, local_trigger_count);
|
2015-01-18 03:14:41 +08:00
|
|
|
break;
|
|
|
|
case -ENODEV:
|
|
|
|
case -ENXIO:
|
|
|
|
pr_debug("%s: probe of %s rejects match %d\n",
|
|
|
|
drv->name, dev_name(dev), ret);
|
|
|
|
break;
|
|
|
|
default:
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
/* driver matched but the probe failed */
|
|
|
|
printk(KERN_WARNING
|
|
|
|
"%s: probe of %s failed with error %d\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->name, dev_name(dev), ret);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
}
|
2006-11-27 17:35:10 +08:00
|
|
|
/*
|
|
|
|
* Ignore errors returned by ->probe so that the next driver can try
|
|
|
|
* its luck.
|
|
|
|
*/
|
|
|
|
ret = 0;
|
2006-07-19 01:59:59 +08:00
|
|
|
done:
|
|
|
|
atomic_dec(&probe_count);
|
2006-10-28 02:42:37 +08:00
|
|
|
wake_up(&probe_waitqueue);
|
2006-07-19 01:59:59 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-21 08:35:56 +08:00
|
|
|
/*
|
|
|
|
* For initcall_debug, show the driver probe time.
|
|
|
|
*/
|
|
|
|
static int really_probe_debug(struct device *dev, struct device_driver *drv)
|
|
|
|
{
|
|
|
|
ktime_t calltime, delta, rettime;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
calltime = ktime_get();
|
|
|
|
ret = really_probe(dev, drv);
|
|
|
|
rettime = ktime_get();
|
|
|
|
delta = ktime_sub(rettime, calltime);
|
|
|
|
printk(KERN_DEBUG "probe of %s returned %d after %lld usecs\n",
|
|
|
|
dev_name(dev), ret, (s64) ktime_to_us(delta));
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2006-07-19 01:59:59 +08:00
|
|
|
/**
|
|
|
|
* driver_probe_done
|
|
|
|
* Determine if the probe sequence is finished or not.
|
|
|
|
*
|
|
|
|
* Should somehow figure out how to use a semaphore, not an atomic variable...
|
|
|
|
*/
|
|
|
|
int driver_probe_done(void)
|
|
|
|
{
|
2008-03-05 08:41:05 +08:00
|
|
|
pr_debug("%s: probe_count = %d\n", __func__,
|
2006-07-19 01:59:59 +08:00
|
|
|
atomic_read(&probe_count));
|
|
|
|
if (atomic_read(&probe_count))
|
|
|
|
return -EBUSY;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-14 08:59:06 +08:00
|
|
|
/**
|
|
|
|
* wait_for_device_probe
|
|
|
|
* Wait for device probing to be completed.
|
|
|
|
*/
|
2009-02-21 16:45:07 +08:00
|
|
|
void wait_for_device_probe(void)
|
2009-02-14 08:59:06 +08:00
|
|
|
{
|
2015-11-10 17:42:34 +08:00
|
|
|
/* wait for the deferred probe workqueue to finish */
|
2016-08-31 01:15:34 +08:00
|
|
|
flush_work(&deferred_probe_work);
|
2015-11-10 17:42:34 +08:00
|
|
|
|
2009-02-14 08:59:06 +08:00
|
|
|
/* wait for the known devices to complete their probing */
|
2009-02-21 16:45:07 +08:00
|
|
|
wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
|
2009-02-14 08:59:06 +08:00
|
|
|
async_synchronize_full();
|
|
|
|
}
|
2009-04-22 04:32:54 +08:00
|
|
|
EXPORT_SYMBOL_GPL(wait_for_device_probe);
|
2009-02-14 08:59:06 +08:00
|
|
|
|
2006-07-19 01:59:59 +08:00
|
|
|
/**
|
|
|
|
* driver_probe_device - attempt to bind device & driver together
|
|
|
|
* @drv: driver to bind a device to
|
|
|
|
* @dev: device to try to bind to the driver
|
|
|
|
*
|
2009-01-21 23:27:47 +08:00
|
|
|
* This function returns -ENODEV if the device is not registered,
|
tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-14 23:09:05 +08:00
|
|
|
* 1 if the device is bound successfully and 0 otherwise.
|
2006-07-19 01:59:59 +08:00
|
|
|
*
|
2010-02-18 02:57:05 +08:00
|
|
|
* This function must be called with @dev lock held. When called for a
|
|
|
|
* USB interface, @dev->parent lock must be held as well.
|
2015-07-27 23:03:58 +08:00
|
|
|
*
|
|
|
|
* If the device has a parent, runtime-resume the parent before driver probing.
|
2006-07-19 01:59:59 +08:00
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
int driver_probe_device(struct device_driver *drv, struct device *dev)
|
2006-07-19 01:59:59 +08:00
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2006-09-19 04:22:34 +08:00
|
|
|
if (!device_is_registered(dev))
|
|
|
|
return -ENODEV;
|
2006-07-19 01:59:59 +08:00
|
|
|
|
2007-11-29 15:49:41 +08:00
|
|
|
pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
|
2008-10-30 08:36:48 +08:00
|
|
|
drv->bus->name, __func__, dev_name(dev), drv->name);
|
2006-07-19 01:59:59 +08:00
|
|
|
|
2018-06-12 16:24:13 +08:00
|
|
|
pm_runtime_get_suppliers(dev);
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2009-08-19 05:38:32 +08:00
|
|
|
pm_runtime_barrier(dev);
|
2018-06-21 08:35:56 +08:00
|
|
|
if (initcall_debug)
|
|
|
|
ret = really_probe_debug(dev, drv);
|
|
|
|
else
|
|
|
|
ret = really_probe(dev, drv);
|
2013-04-10 23:00:48 +08:00
|
|
|
pm_request_idle(dev);
|
2006-07-19 01:59:59 +08:00
|
|
|
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
|
|
|
|
2018-06-12 16:24:13 +08:00
|
|
|
pm_runtime_put_suppliers(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
return ret;
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
bool driver_allows_async_probing(struct device_driver *drv)
|
2005-03-25 02:50:24 +08:00
|
|
|
{
|
2015-03-31 07:20:06 +08:00
|
|
|
switch (drv->probe_type) {
|
|
|
|
case PROBE_PREFER_ASYNCHRONOUS:
|
2015-03-31 07:20:05 +08:00
|
|
|
return true;
|
|
|
|
|
2015-03-31 07:20:06 +08:00
|
|
|
case PROBE_FORCE_SYNCHRONOUS:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
default:
|
2015-05-22 06:49:37 +08:00
|
|
|
if (module_requested_async_probing(drv->owner))
|
2015-03-31 07:20:06 +08:00
|
|
|
return true;
|
2015-03-31 07:20:05 +08:00
|
|
|
|
2015-03-31 07:20:06 +08:00
|
|
|
return false;
|
|
|
|
}
|
2015-03-31 07:20:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
struct device_attach_data {
|
|
|
|
struct device *dev;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Indicates whether we are are considering asynchronous probing or
|
|
|
|
* not. Only initial binding after device or driver registration
|
|
|
|
* (including deferral processing) may be done asynchronously, the
|
|
|
|
* rest is always synchronous, as we expect it is being done by
|
|
|
|
* request from userspace.
|
|
|
|
*/
|
|
|
|
bool check_async;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Indicates if we are binding synchronous or asynchronous drivers.
|
|
|
|
* When asynchronous probing is enabled we'll execute 2 passes
|
|
|
|
* over drivers: first pass doing synchronous probing and second
|
|
|
|
* doing asynchronous probing (if synchronous did not succeed -
|
|
|
|
* most likely because there was no driver requiring synchronous
|
|
|
|
* probing - and we found asynchronous driver during first pass).
|
|
|
|
* The 2 passes are done because we can't shoot asynchronous
|
|
|
|
* probe for given device and driver from bus_for_each_drv() since
|
|
|
|
* driver pointer is not guaranteed to stay valid once
|
|
|
|
* bus_for_each_drv() iterates to the next driver on the bus.
|
|
|
|
*/
|
|
|
|
bool want_async;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We'll set have_async to 'true' if, while scanning for matching
|
|
|
|
* driver, we'll encounter one that requests asynchronous probing.
|
|
|
|
*/
|
|
|
|
bool have_async;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __device_attach_driver(struct device_driver *drv, void *_data)
|
|
|
|
{
|
|
|
|
struct device_attach_data *data = _data;
|
|
|
|
struct device *dev = data->dev;
|
|
|
|
bool async_allowed;
|
2016-02-15 16:25:06 +08:00
|
|
|
int ret;
|
2015-03-31 07:20:04 +08:00
|
|
|
|
2016-02-15 16:25:06 +08:00
|
|
|
ret = driver_match_device(drv, dev);
|
|
|
|
if (ret == 0) {
|
|
|
|
/* no match */
|
2009-01-21 23:27:47 +08:00
|
|
|
return 0;
|
2016-02-15 16:25:06 +08:00
|
|
|
} else if (ret == -EPROBE_DEFER) {
|
|
|
|
dev_dbg(dev, "Device match requests probe deferral\n");
|
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
} else if (ret < 0) {
|
|
|
|
dev_dbg(dev, "Bus failed to match device: %d", ret);
|
|
|
|
return ret;
|
|
|
|
} /* ret > 0 means positive match */
|
2009-01-21 23:27:47 +08:00
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
async_allowed = driver_allows_async_probing(drv);
|
|
|
|
|
|
|
|
if (async_allowed)
|
|
|
|
data->have_async = true;
|
|
|
|
|
|
|
|
if (data->check_async && async_allowed != data->want_async)
|
|
|
|
return 0;
|
|
|
|
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
return driver_probe_device(drv, dev);
|
2005-03-25 02:50:24 +08:00
|
|
|
}
|
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
static void __device_attach_async_helper(void *_dev, async_cookie_t cookie)
|
|
|
|
{
|
|
|
|
struct device *dev = _dev;
|
|
|
|
struct device_attach_data data = {
|
|
|
|
.dev = dev,
|
|
|
|
.check_async = true,
|
|
|
|
.want_async = true,
|
|
|
|
};
|
|
|
|
|
|
|
|
device_lock(dev);
|
|
|
|
|
2019-01-23 02:39:10 +08:00
|
|
|
/*
|
|
|
|
* Check if device has already been removed or claimed. This may
|
|
|
|
* happen with driver loading, device discovery/registration,
|
|
|
|
* and deferred probe processing happens all at once with
|
|
|
|
* multiple threads.
|
|
|
|
*/
|
|
|
|
if (dev->p->dead || dev->driver)
|
|
|
|
goto out_unlock;
|
|
|
|
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
bus_for_each_drv(dev->bus, NULL, &data, __device_attach_driver);
|
|
|
|
dev_dbg(dev, "async probe completed\n");
|
|
|
|
|
|
|
|
pm_request_idle(dev);
|
|
|
|
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
2019-01-23 02:39:10 +08:00
|
|
|
out_unlock:
|
2015-03-31 07:20:04 +08:00
|
|
|
device_unlock(dev);
|
|
|
|
|
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2015-05-21 07:36:31 +08:00
|
|
|
static int __device_attach(struct device *dev, bool allow_async)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2010-02-18 02:57:05 +08:00
|
|
|
device_lock(dev);
|
2005-03-22 02:52:54 +08:00
|
|
|
if (dev->driver) {
|
2016-01-07 23:46:12 +08:00
|
|
|
if (device_is_bound(dev)) {
|
2011-04-13 01:05:37 +08:00
|
|
|
ret = 1;
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
2006-08-15 13:43:20 +08:00
|
|
|
ret = device_bind_driver(dev);
|
|
|
|
if (ret == 0)
|
|
|
|
ret = 1;
|
2007-02-06 08:15:26 +08:00
|
|
|
else {
|
|
|
|
dev->driver = NULL;
|
|
|
|
ret = 0;
|
|
|
|
}
|
2007-02-06 08:15:25 +08:00
|
|
|
} else {
|
2015-03-31 07:20:04 +08:00
|
|
|
struct device_attach_data data = {
|
|
|
|
.dev = dev,
|
|
|
|
.check_async = allow_async,
|
|
|
|
.want_async = false,
|
|
|
|
};
|
|
|
|
|
2015-07-27 23:03:58 +08:00
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_get_sync(dev->parent);
|
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
ret = bus_for_each_drv(dev->bus, NULL, &data,
|
|
|
|
__device_attach_driver);
|
|
|
|
if (!ret && allow_async && data.have_async) {
|
|
|
|
/*
|
|
|
|
* If we could not find appropriate driver
|
|
|
|
* synchronously and we are allowed to do
|
|
|
|
* async probes and there are drivers that
|
|
|
|
* want to probe asynchronously, we'll
|
|
|
|
* try them.
|
|
|
|
*/
|
|
|
|
dev_dbg(dev, "scheduling asynchronous probe\n");
|
|
|
|
get_device(dev);
|
|
|
|
async_schedule(__device_attach_async_helper, dev);
|
|
|
|
} else {
|
|
|
|
pm_request_idle(dev);
|
|
|
|
}
|
2015-07-27 23:03:58 +08:00
|
|
|
|
|
|
|
if (dev->parent)
|
|
|
|
pm_runtime_put(dev->parent);
|
2007-02-06 08:15:25 +08:00
|
|
|
}
|
2011-04-13 01:05:37 +08:00
|
|
|
out_unlock:
|
2010-02-18 02:57:05 +08:00
|
|
|
device_unlock(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
return ret;
|
2005-03-25 02:50:24 +08:00
|
|
|
}
|
2015-03-31 07:20:04 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* device_attach - try to attach device to a driver.
|
|
|
|
* @dev: device.
|
|
|
|
*
|
|
|
|
* Walk the list of drivers that the bus has and call
|
|
|
|
* driver_probe_device() for each pair. If a compatible
|
|
|
|
* pair is found, break out and return.
|
|
|
|
*
|
|
|
|
* Returns 1 if the device was bound to a driver;
|
|
|
|
* 0 if no matching driver was found;
|
|
|
|
* -ENODEV if the device is not registered.
|
|
|
|
*
|
|
|
|
* When called for a USB interface, @dev->parent lock must be held.
|
|
|
|
*/
|
|
|
|
int device_attach(struct device *dev)
|
|
|
|
{
|
|
|
|
return __device_attach(dev, false);
|
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_attach);
|
2005-03-25 02:50:24 +08:00
|
|
|
|
2015-03-31 07:20:04 +08:00
|
|
|
void device_initial_probe(struct device *dev)
|
|
|
|
{
|
|
|
|
__device_attach(dev, true);
|
|
|
|
}
|
|
|
|
|
2019-01-23 02:39:16 +08:00
|
|
|
/*
|
|
|
|
* __device_driver_lock - acquire locks needed to manipulate dev->drv
|
|
|
|
* @dev: Device we will update driver info for
|
|
|
|
* @parent: Parent device. Needed if the bus requires parent lock
|
|
|
|
*
|
|
|
|
* This function will take the required locks for manipulating dev->drv.
|
|
|
|
* Normally this will just be the @dev lock, but when called for a USB
|
|
|
|
* interface, @parent lock will be held as well.
|
|
|
|
*/
|
|
|
|
static void __device_driver_lock(struct device *dev, struct device *parent)
|
|
|
|
{
|
|
|
|
if (parent && dev->bus->need_parent_lock)
|
|
|
|
device_lock(parent);
|
|
|
|
device_lock(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* __device_driver_unlock - release locks needed to manipulate dev->drv
|
|
|
|
* @dev: Device we will update driver info for
|
|
|
|
* @parent: Parent device. Needed if the bus requires parent lock
|
|
|
|
*
|
|
|
|
* This function will release the required locks for manipulating dev->drv.
|
|
|
|
* Normally this will just be the the @dev lock, but when called for a
|
|
|
|
* USB interface, @parent lock will be released as well.
|
|
|
|
*/
|
|
|
|
static void __device_driver_unlock(struct device *dev, struct device *parent)
|
|
|
|
{
|
|
|
|
device_unlock(dev);
|
|
|
|
if (parent && dev->bus->need_parent_lock)
|
|
|
|
device_unlock(parent);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* device_driver_attach - attach a specific driver to a specific device
|
|
|
|
* @drv: Driver to attach
|
|
|
|
* @dev: Device to attach it to
|
|
|
|
*
|
|
|
|
* Manually attach driver to a device. Will acquire both @dev lock and
|
|
|
|
* @dev->parent lock if needed.
|
|
|
|
*/
|
|
|
|
int device_driver_attach(struct device_driver *drv, struct device *dev)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
__device_driver_lock(dev, dev->parent);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If device has been removed or someone has already successfully
|
|
|
|
* bound a driver before us just skip the driver probe call.
|
|
|
|
*/
|
|
|
|
if (!dev->p->dead && !dev->driver)
|
|
|
|
ret = driver_probe_device(drv, dev);
|
|
|
|
|
|
|
|
__device_driver_unlock(dev, dev->parent);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-01-25 14:50:12 +08:00
|
|
|
static int __driver_attach(struct device *dev, void *data)
|
2005-03-25 02:50:24 +08:00
|
|
|
{
|
2008-01-25 14:50:12 +08:00
|
|
|
struct device_driver *drv = data;
|
2016-02-15 16:25:06 +08:00
|
|
|
int ret;
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Lock device and try to bind to it. We drop the error
|
|
|
|
* here and always return 0, because we need to keep trying
|
|
|
|
* to bind to devices and some drivers will return an error
|
|
|
|
* simply if it didn't support the device.
|
|
|
|
*
|
|
|
|
* driver_probe_device() will spit a warning if there
|
|
|
|
* is an error.
|
|
|
|
*/
|
|
|
|
|
2016-02-15 16:25:06 +08:00
|
|
|
ret = driver_match_device(drv, dev);
|
|
|
|
if (ret == 0) {
|
|
|
|
/* no match */
|
2008-09-14 23:32:06 +08:00
|
|
|
return 0;
|
2016-02-15 16:25:06 +08:00
|
|
|
} else if (ret == -EPROBE_DEFER) {
|
|
|
|
dev_dbg(dev, "Device match requests probe deferral\n");
|
|
|
|
driver_deferred_probe_add(dev);
|
|
|
|
} else if (ret < 0) {
|
|
|
|
dev_dbg(dev, "Bus failed to match device: %d", ret);
|
|
|
|
return ret;
|
|
|
|
} /* ret > 0 means positive match */
|
2008-09-14 23:32:06 +08:00
|
|
|
|
2019-01-23 02:39:16 +08:00
|
|
|
device_driver_attach(drv, dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
|
2005-03-22 02:52:54 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-01-25 14:50:12 +08:00
|
|
|
* driver_attach - try to bind driver to devices.
|
|
|
|
* @drv: driver.
|
2005-03-22 02:52:54 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Walk the list of devices that the bus has on it and try to
|
|
|
|
* match the driver with each one. If driver_probe_device()
|
|
|
|
* returns 0 and the @dev->driver is set, we've found a
|
|
|
|
* compatible pair.
|
2005-03-22 02:52:54 +08:00
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
int driver_attach(struct device_driver *drv)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2006-08-15 13:43:20 +08:00
|
|
|
return bus_for_each_dev(drv->bus, NULL, drv, __driver_attach);
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(driver_attach);
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2007-06-17 17:02:12 +08:00
|
|
|
/*
|
2010-02-18 02:57:05 +08:00
|
|
|
* __device_release_driver() must be called with @dev lock held.
|
|
|
|
* When called for a USB interface, @dev->parent lock must be held as well.
|
2005-03-22 02:52:54 +08:00
|
|
|
*/
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
static void __device_release_driver(struct device *dev, struct device *parent)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2008-01-25 14:50:12 +08:00
|
|
|
struct device_driver *drv;
|
2005-03-22 02:52:54 +08:00
|
|
|
|
2007-11-17 00:57:28 +08:00
|
|
|
drv = dev->driver;
|
2005-05-07 03:38:33 +08:00
|
|
|
if (drv) {
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
while (device_links_busy(dev)) {
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_unlock(dev, parent);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
|
|
|
|
device_links_unbind_consumers(dev);
|
|
|
|
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_lock(dev, parent);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
/*
|
|
|
|
* A concurrent invocation of the same function might
|
|
|
|
* have released the driver successfully while this one
|
|
|
|
* was waiting, so check for that.
|
|
|
|
*/
|
|
|
|
if (dev->driver != drv)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-04-29 06:33:45 +08:00
|
|
|
pm_runtime_get_sync(dev);
|
2016-10-31 00:32:31 +08:00
|
|
|
pm_runtime_clean_up_links(dev);
|
2009-08-19 05:38:32 +08:00
|
|
|
|
2006-10-08 03:55:55 +08:00
|
|
|
driver_sysfs_remove(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
if (dev->bus)
|
2007-11-02 10:41:16 +08:00
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
BUS_NOTIFY_UNBIND_DRIVER,
|
|
|
|
dev);
|
|
|
|
|
2013-11-07 08:51:15 +08:00
|
|
|
pm_runtime_put_sync(dev);
|
2011-04-29 06:33:45 +08:00
|
|
|
|
2006-04-01 00:52:25 +08:00
|
|
|
if (dev->bus && dev->bus->remove)
|
2006-01-05 22:29:51 +08:00
|
|
|
dev->bus->remove(dev);
|
|
|
|
else if (drv->remove)
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
drv->remove(dev);
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
|
|
|
|
device_links_driver_cleanup(dev);
|
2018-08-24 16:28:18 +08:00
|
|
|
arch_teardown_dma_ops(dev);
|
2017-04-10 19:21:01 +08:00
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
devres_release_all(dev);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
dev->driver = NULL;
|
2012-05-23 06:09:34 +08:00
|
|
|
dev_set_drvdata(dev, NULL);
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 20:59:27 +08:00
|
|
|
if (dev->pm_domain && dev->pm_domain->dismiss)
|
|
|
|
dev->pm_domain->dismiss(dev);
|
PM / runtime: Re-init runtime PM states at probe error and driver unbind
There are two common expectations among several subsystems/drivers that
deploys runtime PM support, but which isn't met by the driver core.
Expectation 1)
At ->probe() the subsystem/driver expects the runtime PM status of the
device to be RPM_SUSPENDED, which is the initial status being assigned at
device registration.
This expectation is especially common among some of those subsystems/
drivers that manages devices with an attached PM domain, as those requires
the ->runtime_resume() callback at the PM domain level to be invoked
during ->probe().
Moreover these subsystems/drivers entirely relies on runtime PM resources
being managed at the PM domain level, thus don't implement their own set
of runtime PM callbacks.
These are two scenarios that suffers from this unmet expectation.
i) A failed ->probe() sequence requests probe deferral:
->probe()
...
pm_runtime_enable()
pm_runtime_get_sync()
...
err:
pm_runtime_put()
pm_runtime_disable()
...
As there are no guarantees that such sequence turns the runtime PM status
of the device into RPM_SUSPENDED, the re-trying ->probe() may start with
the status in RPM_ACTIVE.
In such case the runtime PM core won't invoke the ->runtime_resume()
callback because of a pm_runtime_get_sync(), as it considers the device to
be already runtime resumed.
ii) A driver re-bind sequence:
At driver unbind, the subsystem/driver's >remove() callback invokes a
sequence of runtime PM APIs, to undo actions during ->probe() and to put
the device into low power state.
->remove()
...
pm_runtime_put()
pm_runtime_disable()
...
Similar as in the failing ->probe() case, this sequence don't guarantee
the runtime PM status of the device to turn into RPM_SUSPENDED.
Trying to re-bind the driver thus causes the same issue as when re-trying
->probe(), in the probe deferral scenario.
Expectation 2)
Drivers that invokes the pm_runtime_irq_safe() API during ->probe(),
triggers the runtime PM core to increase the usage count for the device's
parent and permanently make it runtime resumed.
The usage count is only dropped at device removal, which also allows it to
be runtime suspended again.
A re-trying ->probe() repeats the call to pm_runtime_irq_safe() and thus
once more triggers the usage count of the device's parent to be increased.
This leads to not only an imbalance issue of the usage count of the
device's parent, but also to keep it runtime resumed permanently even if
->probe() fails.
To address these issues, let's change the policy of the driver core to
meet these expectations. More precisely, at ->probe() failures and driver
unbind, restore the initial states of runtime PM.
Although to still allow subsystem's to control PM for devices that doesn't
->probe() successfully, don't restore the initial states unless runtime PM
is disabled.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-18 18:48:39 +08:00
|
|
|
pm_runtime_reinit(dev);
|
PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags
The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.
The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.
To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers. Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.
Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.
While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-25 20:12:29 +08:00
|
|
|
dev_pm_set_driver_flags(dev, 0);
|
driver core / PM: Add PM domain callbacks for device setup/cleanup
If PM domains are in use, it may be necessary to prepare the code
handling a PM domain for driver probing. For example, in some
cases device drivers rely on the ability to power on the devices
with the help of the IO runtime PM framework and the PM domain
code needs to be ready for that. Also, if that code has not been
fully initialized yet, the driver probing should be deferred.
Moreover, after the probing is complete, it may be necessary to
put the PM domain in question into the state reflecting the current
needs of the devices in it, for example, so that power is not drawn
in vain. The same should be done after removing a driver from
a device, as the PM domain state may need to be changed to reflect
the new situation.
For these reasons, introduce new PM domain callbacks, ->activate,
->sync and ->dismiss called, respectively, before probing for a
device driver, after the probing has completed successfully and
if the probing has failed or the driver has been removed.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-20 20:59:27 +08:00
|
|
|
|
2008-12-17 04:25:49 +08:00
|
|
|
klist_remove(&dev->p->knode_driver);
|
2016-01-07 23:46:14 +08:00
|
|
|
device_pm_check_callbacks(dev);
|
2009-04-24 20:57:00 +08:00
|
|
|
if (dev->bus)
|
|
|
|
blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
|
|
|
|
BUS_NOTIFY_UNBOUND_DRIVER,
|
|
|
|
dev);
|
2017-07-20 08:24:30 +08:00
|
|
|
|
|
|
|
kobject_uevent(&dev->kobj, KOBJ_UNBIND);
|
[PATCH] Driver Core: fix bk-driver-core kills ppc64
There's no check to see if the device is already bound to a driver, which
could do bad things. The first thing to go wrong is that it will try to match
a driver with a device already bound to one. In some cases (it appears with
USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a
device based on the class type, so it would be common (especially for HID
devices) to match a device that is already bound.
The fun comes when ->probe() is called, it fails, then
driver_probe_device() does this:
dev->driver = NULL;
Later on, that pointer could be be dereferenced without checking and cause
hell to break loose.
This problem could be nasty. It's very hardware dependent, since some
devices could have a different set of matching qualifiers than others.
Now, I don't quite see exactly where/how you were getting that crash.
You're dereferencing bad memory, but I'm not sure which pointer was bad
and where it came from, but it could have come from a couple of different
places.
The patch below will hopefully fix it all up for you. It's against
2.6.12-rc2-mm1, and does the following:
- Move logic to driver_probe_device() and comments uncommon returns:
1 - If device is bound
0 - If device not bound, and no error
error - If there was an error.
- Move locking to caller of that function, since we want to lock a
device for the entire time we're trying to bind it to a driver (to
prevent against a driver being loaded at the same time).
- Update __device_attach() and __driver_attach() to do that locking.
- Check if device is already bound in __driver_attach()
- Update the converse device_release_driver() so it locks the device
around all of the operations.
- Mark driver_probe_device() as static and remove export. It's an
internal function, it should stay that way, and there are no other
callers. If there is ever a need to export it, we can audit it as
necessary.
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-04-06 14:46:33 +08:00
|
|
|
}
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|
|
|
|
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
void device_release_driver_internal(struct device *dev,
|
|
|
|
struct device_driver *drv,
|
|
|
|
struct device *parent)
|
2016-10-10 20:37:56 +08:00
|
|
|
{
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_lock(dev, parent);
|
2016-10-10 20:37:56 +08:00
|
|
|
|
|
|
|
if (!drv || drv == dev->driver)
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
__device_release_driver(dev, parent);
|
2016-10-10 20:37:56 +08:00
|
|
|
|
2019-01-23 02:39:16 +08:00
|
|
|
__device_driver_unlock(dev, parent);
|
2016-10-10 20:37:56 +08:00
|
|
|
}
|
|
|
|
|
2007-06-17 17:02:12 +08:00
|
|
|
/**
|
2008-01-25 14:50:12 +08:00
|
|
|
* device_release_driver - manually detach device from driver.
|
|
|
|
* @dev: device.
|
2007-06-17 17:02:12 +08:00
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* Manually detach device from driver.
|
2010-02-18 02:57:05 +08:00
|
|
|
* When called for a USB interface, @dev->parent lock must be held.
|
driver core: Functional dependencies tracking support
Currently, there is a problem with taking functional dependencies
between devices into account.
What I mean by a "functional dependency" is when the driver of device
B needs device A to be functional and (generally) its driver to be
present in order to work properly. This has certain consequences
for power management (suspend/resume and runtime PM ordering) and
shutdown ordering of these devices. In general, it also implies that
the driver of A needs to be working for B to be probed successfully
and it cannot be unbound from the device before the B's driver.
Support for representing those functional dependencies between
devices is added here to allow the driver core to track them and act
on them in certain cases where applicable.
The argument for doing that in the driver core is that there are
quite a few distinct use cases involving device dependencies, they
are relatively hard to get right in a driver (if one wants to
address all of them properly) and it only gets worse if multiplied
by the number of drivers potentially needing to do it. Morever, at
least one case (asynchronous system suspend/resume) cannot be handled
in a single driver at all, because it requires the driver of A to
wait for B to suspend (during system suspend) and the driver of B to
wait for A to resume (during system resume).
For this reason, represent dependencies between devices as "links",
with the help of struct device_link objects each containing pointers
to the "linked" devices, a list node for each of them, status
information, flags, and an RCU head for synchronization.
Also add two new list heads, representing the lists of links to the
devices that depend on the given one (consumers) and to the devices
depended on by it (suppliers), and a "driver presence status" field
(needed for figuring out initial states of device links) to struct
device.
The entire data structure consisting of all of the lists of link
objects for all devices is protected by a mutex (for link object
addition/removal and for list walks during device driver probing
and removal) and by SRCU (for list walking in other case that will
be introduced by subsequent change sets). If CONFIG_SRCU is not
selected, however, an rwsem is used for protecting the entire data
structure.
In addition, each link object has an internal status field whose
value reflects whether or not drivers are bound to the devices
pointed to by the link or probing/removal of their drivers is in
progress etc. That field is only modified under the device links
mutex, but it may be read outside of it in some cases (introduced by
subsequent change sets), so modifications of it are annotated with
WRITE_ONCE().
New links are added by calling device_link_add() which takes three
arguments: pointers to the devices in question and flags. In
particular, if DL_FLAG_STATELESS is set in the flags, the link status
is not to be taken into account for this link and the driver core
will not manage it. In turn, if DL_FLAG_AUTOREMOVE is set in the
flags, the driver core will remove the link automatically when the
consumer device driver unbinds from it.
One of the actions carried out by device_link_add() is to reorder
the lists used for device shutdown and system suspend/resume to
put the consumer device along with all of its children and all of
its consumers (and so on, recursively) to the ends of those lists
in order to ensure the right ordering between all of the supplier
and consumer devices.
For this reason, it is not possible to create a link between two
devices if the would-be supplier device already depends on the
would-be consumer device as either a direct descendant of it or a
consumer of one of its direct descendants or one of its consumers
and so on.
There are two types of link objects, persistent and non-persistent.
The persistent ones stay around until one of the target devices is
deleted, while the non-persistent ones are removed automatically when
the consumer driver unbinds from its device (ie. they are assumed to
be valid only as long as the consumer device has a driver bound to
it). Persistent links are created by default and non-persistent
links are created when the DL_FLAG_AUTOREMOVE flag is passed
to device_link_add().
Both persistent and non-persistent device links can be deleted
with an explicit call to device_link_del().
Links created without the DL_FLAG_STATELESS flag set are managed
by the driver core using a simple state machine. There are 5 states
each link can be in: DORMANT (unused), AVAILABLE (the supplier driver
is present and functional), CONSUMER_PROBE (the consumer driver is
probing), ACTIVE (both supplier and consumer drivers are present and
functional), and SUPPLIER_UNBIND (the supplier driver is unbinding).
The driver core updates the link state automatically depending on
what happens to the linked devices and for each link state specific
actions are taken in addition to that.
For example, if the supplier driver unbinds from its device, the
driver core will also unbind the drivers of all of its consumers
automatically under the assumption that they cannot function
properly without the supplier. Analogously, the driver core will
only allow the consumer driver to bind to its device if the
supplier driver is present and functional (ie. the link is in
the AVAILABLE state). If that's not the case, it will rely on
the existing deferred probing mechanism to wait for the supplier
driver to become available.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-10-31 00:32:16 +08:00
|
|
|
*
|
|
|
|
* If this function is to be called with @dev->parent lock held, ensure that
|
|
|
|
* the device's consumers are unbound in advance or that their locks can be
|
|
|
|
* acquired under the @dev->parent lock.
|
2007-06-17 17:02:12 +08:00
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
void device_release_driver(struct device *dev)
|
2005-03-22 04:25:36 +08:00
|
|
|
{
|
2005-05-07 03:38:33 +08:00
|
|
|
/*
|
|
|
|
* If anyone calls device_release_driver() recursively from
|
|
|
|
* within their ->remove callback for the same device, they
|
|
|
|
* will deadlock right here.
|
|
|
|
*/
|
2016-10-10 20:37:56 +08:00
|
|
|
device_release_driver_internal(dev, NULL, NULL);
|
2005-03-22 04:25:36 +08:00
|
|
|
}
|
2008-01-25 14:50:12 +08:00
|
|
|
EXPORT_SYMBOL_GPL(device_release_driver);
|
2005-05-07 03:38:33 +08:00
|
|
|
|
2019-01-23 02:39:16 +08:00
|
|
|
/**
|
|
|
|
* device_driver_detach - detach driver from a specific device
|
|
|
|
* @dev: device to detach driver from
|
|
|
|
*
|
|
|
|
* Detach driver from device. Will acquire both @dev lock and @dev->parent
|
|
|
|
* lock if needed.
|
|
|
|
*/
|
|
|
|
void device_driver_detach(struct device *dev)
|
|
|
|
{
|
|
|
|
device_release_driver_internal(dev, NULL, dev->parent);
|
|
|
|
}
|
|
|
|
|
2005-03-22 02:52:54 +08:00
|
|
|
/**
|
|
|
|
* driver_detach - detach driver from all devices it controls.
|
|
|
|
* @drv: driver.
|
|
|
|
*/
|
2008-01-25 14:50:12 +08:00
|
|
|
void driver_detach(struct device_driver *drv)
|
2005-03-22 02:52:54 +08:00
|
|
|
{
|
2008-12-17 04:25:49 +08:00
|
|
|
struct device_private *dev_prv;
|
2008-01-25 14:50:12 +08:00
|
|
|
struct device *dev;
|
2005-05-07 03:38:33 +08:00
|
|
|
|
2018-11-29 08:32:11 +08:00
|
|
|
if (driver_allows_async_probing(drv))
|
|
|
|
async_synchronize_full();
|
|
|
|
|
2005-05-07 03:38:33 +08:00
|
|
|
for (;;) {
|
2007-11-29 07:59:15 +08:00
|
|
|
spin_lock(&drv->p->klist_devices.k_lock);
|
|
|
|
if (list_empty(&drv->p->klist_devices.k_list)) {
|
|
|
|
spin_unlock(&drv->p->klist_devices.k_lock);
|
2005-05-07 03:38:33 +08:00
|
|
|
break;
|
|
|
|
}
|
2008-12-17 04:25:49 +08:00
|
|
|
dev_prv = list_entry(drv->p->klist_devices.k_list.prev,
|
|
|
|
struct device_private,
|
|
|
|
knode_driver.n_node);
|
|
|
|
dev = dev_prv->device;
|
2005-05-07 03:38:33 +08:00
|
|
|
get_device(dev);
|
2007-11-29 07:59:15 +08:00
|
|
|
spin_unlock(&drv->p->klist_devices.k_lock);
|
2016-10-10 20:37:56 +08:00
|
|
|
device_release_driver_internal(dev, drv, dev->parent);
|
2005-05-07 03:38:33 +08:00
|
|
|
put_device(dev);
|
|
|
|
}
|
2005-03-22 02:52:54 +08:00
|
|
|
}
|