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
|
|
|
*
|
2008-01-25 14:50:12 +08:00
|
|
|
* This file is released under the GPLv2
|
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>
|
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);
|
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.
|
|
|
|
*/
|
|
|
|
device_pm_lock();
|
|
|
|
device_pm_move_last(dev);
|
|
|
|
device_pm_unlock();
|
|
|
|
|
2012-03-05 23:47:41 +08:00
|
|
|
dev_dbg(dev, "Retrying from deferred list\n");
|
|
|
|
bus_probe_device(dev);
|
2012-07-05 21:04:44 +08:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
* device_block_probing() - Block/defere device's probes
|
|
|
|
*
|
|
|
|
* 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();
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
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);
|
2012-03-05 23:47:41 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(deferred_probe_initcall);
|
2005-03-22 02:52:54 +08:00
|
|
|
|
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);
|
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,
|
2005-03-22 02:52:54 +08:00
|
|
|
kobject_name(&dev->kobj));
|
2006-08-15 13:43:20 +08:00
|
|
|
if (ret == 0) {
|
2007-11-29 07:59:15 +08:00
|
|
|
ret = sysfs_create_link(&dev->kobj, &dev->driver->p->kobj,
|
2006-08-15 13:43:20 +08:00
|
|
|
"driver");
|
|
|
|
if (ret)
|
2007-11-29 07:59:15 +08:00
|
|
|
sysfs_remove_link(&dev->driver->p->kobj,
|
2006-08-15 13:43:20 +08:00
|
|
|
kobject_name(&dev->kobj));
|
|
|
|
}
|
|
|
|
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) {
|
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);
|
|
|
|
|
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
|
|
|
|
* device_defer_all_probes_enable() which, in turn, will call
|
|
|
|
* 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);
|
|
|
|
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
|
|
|
|
2017-04-10 19:21:01 +08:00
|
|
|
ret = dma_configure(dev);
|
|
|
|
if (ret)
|
|
|
|
goto dma_failed;
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
driver core: correct device's shutdown order
Now device's shutdown sequence is performed in reverse order of their
registration in devices_kset list and this sequence corresponds to the
reverse device's creation order. So, devices_kset data tracks
"parent<-child" device's dependencies only.
Unfortunately, that's not enough and causes problems in case of
implementing board's specific shutdown procedures. For example [1]:
"DRA7XX_evm uses PCF8575 and one of the PCF output lines feeds to
MMC/SD and this line should be driven high in order for the MMC/SD to
be detected. This line is modelled as regulator and the hsmmc driver
takes care of enabling and disabling it. In the case of 'reboot',
during shutdown path as part of it's cleanup process the hsmmc driver
disables this regulator. This makes MMC boot not functional."
To handle this issue the .shutdown() callback could be implemented
for PCF8575 device where corresponding GPIO pins will be configured to
states, required for correct warm/cold reset. This can be achieved
only when all .shutdown() callbacks have been called already for all
PCF8575's consumers. But devices_kset is not filled correctly now:
devices_kset: Device61 4e000000.dmm
devices_kset: Device62 48070000.i2c
devices_kset: Device63 48072000.i2c
devices_kset: Device64 48060000.i2c
devices_kset: Device65 4809c000.mmc
...
devices_kset: Device102 fixedregulator-sd
...
devices_kset: Device181 0-0020 // PCF8575
devices_kset: Device182 gpiochip496
devices_kset: Device183 0-0021 // PCF8575
devices_kset: Device184 gpiochip480
As can be seen from above .shutdown() callback for PCF8575 will be called
before its consumers, which, in turn means, that any changes of PCF8575
GPIO's pins will be or unsafe or overwritten later by GPIO's consumers.
The problem can be solved if devices_kset list will be filled not only
according device creation order, but also according device's probing
order to track "supplier<-consumer" dependencies also.
Hence, as a fix, lets add devices_kset_move_last(),
devices_kset_move_before(), devices_kset_move_after() and call them
from device_move() and also add call of devices_kset_move_last() in
really_probe(). After this change all entries in devices_kset will
be sorted according to device's creation ("parent<-child") and
probing ("supplier<-consumer") order.
devices_kset after:
devices_kset: Device121 48070000.i2c
devices_kset: Device122 i2c-0
...
devices_kset: Device147 regulator.24
devices_kset: Device148 0-0020
devices_kset: Device149 gpiochip496
devices_kset: Device150 0-0021
devices_kset: Device151 gpiochip480
devices_kset: Device152 0-0019
...
devices_kset: Device372 fixedregulator-sd
devices_kset: Device373 regulator.29
devices_kset: Device374 4809c000.mmc
devices_kset: Device375 mmc0
[1] http://www.spinics.net/lists/linux-mmc/msg29825.html
Cc: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-07-28 01:43:01 +08:00
|
|
|
/*
|
|
|
|
* Ensure devices are listed in devices_kset in correct order
|
|
|
|
* It's important to move Dev to the end of devices_kset before
|
|
|
|
* calling .probe, because it could be recursive and parent Dev
|
|
|
|
* should always go first
|
|
|
|
*/
|
|
|
|
devices_kset_move_last(dev);
|
|
|
|
|
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:
|
2017-04-10 19:21:01 +08:00
|
|
|
dma_deconfigure(dev);
|
|
|
|
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);
|
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);
|
2012-03-05 23:47:41 +08:00
|
|
|
driver_deferred_probe_add(dev);
|
2014-04-29 19:05:22 +08:00
|
|
|
/* 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();
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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
|
|
|
|
2016-10-31 00:32:31 +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);
|
2007-02-06 08:15:25 +08:00
|
|
|
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);
|
|
|
|
|
2016-10-31 00:32:31 +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
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if device has already been claimed. This may
|
|
|
|
* happen with driver loading, device discovery/registration,
|
|
|
|
* and deferred probe processing happens all at once with
|
|
|
|
* multiple threads.
|
|
|
|
*/
|
|
|
|
if (dev->driver)
|
|
|
|
return -EBUSY;
|
2009-01-21 23:27:47 +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);
|
|
|
|
|
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);
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
[PATCH] Hold the device's parent's lock during probe and remove
This patch (as604) makes the driver core hold a device's parent's lock
as well as the device's lock during calls to the probe and remove
methods in a driver. This facility is needed by USB device drivers,
owing to the peculiar way USB devices work:
A device provides multiple interfaces, and drivers are bound
to interfaces rather than to devices;
Nevertheless a reset, reset-configuration, suspend, or resume
affects the entire device and requires the caller to hold the
lock for the device, not just a lock for one of the interfaces.
Since a USB driver's probe method is always called with the interface
lock held, the locking order rules (always lock parent before child)
prevent these methods from acquiring the device lock. The solution
provided here is to call all probe and remove methods, for all devices
(not just USB), with the parent lock already acquired.
Although currently only the USB subsystem requires these changes, people
have mentioned in prior discussion that the overhead of acquiring an
extra semaphore in all the prove/remove sequences is not overly large.
Up to now, the USB core has been using its own set of private
semaphores. A followup patch will remove them, relying entirely on the
device semaphores provided by the driver core.
The code paths affected by this patch are:
device_add and device_del: The USB core already holds the parent
lock, so no actual change is needed.
driver_register and driver_unregister: The driver core will now
lock both the parent and the device before probing or removing.
driver_bind and driver_unbind (in sysfs): These routines will
now lock both the parent and the device before binding or
unbinding.
bus_rescan_devices: The helper routine will lock the parent
before probing a device.
I have not tested this patch for conflicts with other subsystems. As
far as I can see, the only possibility of conflict would lie in the
bus_rescan_devices pathway, and it seems pretty remote. Nevertheless,
it would be good for this to get a lot of testing in -mm.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-18 05:54:12 +08:00
|
|
|
if (dev->parent) /* Needed for USB */
|
2010-02-18 02:57:05 +08:00
|
|
|
device_lock(dev->parent);
|
|
|
|
device_lock(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
|
|
|
if (!dev->driver)
|
|
|
|
driver_probe_device(drv, dev);
|
2010-02-18 02:57:05 +08:00
|
|
|
device_unlock(dev);
|
[PATCH] Hold the device's parent's lock during probe and remove
This patch (as604) makes the driver core hold a device's parent's lock
as well as the device's lock during calls to the probe and remove
methods in a driver. This facility is needed by USB device drivers,
owing to the peculiar way USB devices work:
A device provides multiple interfaces, and drivers are bound
to interfaces rather than to devices;
Nevertheless a reset, reset-configuration, suspend, or resume
affects the entire device and requires the caller to hold the
lock for the device, not just a lock for one of the interfaces.
Since a USB driver's probe method is always called with the interface
lock held, the locking order rules (always lock parent before child)
prevent these methods from acquiring the device lock. The solution
provided here is to call all probe and remove methods, for all devices
(not just USB), with the parent lock already acquired.
Although currently only the USB subsystem requires these changes, people
have mentioned in prior discussion that the overhead of acquiring an
extra semaphore in all the prove/remove sequences is not overly large.
Up to now, the USB core has been using its own set of private
semaphores. A followup patch will remove them, relying entirely on the
device semaphores provided by the driver core.
The code paths affected by this patch are:
device_add and device_del: The USB core already holds the parent
lock, so no actual change is needed.
driver_register and driver_unregister: The driver core will now
lock both the parent and the device before probing or removing.
driver_bind and driver_unbind (in sysfs): These routines will
now lock both the parent and the device before binding or
unbinding.
bus_rescan_devices: The helper routine will lock the parent
before probing a device.
I have not tested this patch for conflicts with other subsystems. As
far as I can see, the only possibility of conflict would lie in the
bus_rescan_devices pathway, and it seems pretty remote. Nevertheless,
it would be good for this to get a lot of testing in -mm.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-18 05:54:12 +08:00
|
|
|
if (dev->parent)
|
2010-02-18 02:57:05 +08:00
|
|
|
device_unlock(dev->parent);
|
[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) {
|
2015-03-31 07:20:04 +08:00
|
|
|
if (driver_allows_async_probing(drv))
|
|
|
|
async_synchronize_full();
|
|
|
|
|
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)) {
|
|
|
|
device_unlock(dev);
|
|
|
|
if (parent)
|
|
|
|
device_unlock(parent);
|
|
|
|
|
|
|
|
device_links_unbind_consumers(dev);
|
|
|
|
if (parent)
|
|
|
|
device_lock(parent);
|
|
|
|
|
|
|
|
device_lock(dev);
|
|
|
|
/*
|
|
|
|
* 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);
|
2017-04-10 19:21:01 +08:00
|
|
|
dma_deconfigure(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);
|
[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);
|
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);
|
[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
|
|
|
{
|
|
|
|
if (parent)
|
|
|
|
device_lock(parent);
|
|
|
|
|
|
|
|
device_lock(dev);
|
|
|
|
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
|
|
|
|
|
|
|
device_unlock(dev);
|
|
|
|
if (parent)
|
|
|
|
device_unlock(parent);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
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
|
|
|
}
|